Pedro Alves [Mon, 11 Jan 2021 20:01:58 +0000 (20:01 +0000)]
detach in all-stop with threads running
A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process, while threads are running. If we have more then one inferior
running, and we detach from just one of the inferiors, we expect that
the remaining inferior continues running. However, in all-stop, if
GDB needs to pause the target for the detach, nothing is re-resuming
the other inferiors after the detach. "info threads" shows the
threads as running, but they really aren't. This fixes it.
gdb/ChangeLog:
* infcmd.c (detach_command): Hold strong reference to target, and
if all-stop on entry, restart threads on exit.
* infrun.c (switch_back_to_stepped_thread): Factor out bits to ...
(restart_stepped_thread): ... this new function. Also handle
trap_expected.
(restart_after_all_stop_detach): New function.
* infrun.h (restart_after_all_stop_detach): Declare.
Pedro Alves [Mon, 11 Jan 2021 23:11:57 +0000 (23:11 +0000)]
detach with in-line step over in progress
A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process. That testcase exercises both "set displaced-stepping
on/off". Testing with "set displaced-stepping off" reveals that GDB
does not handle the case of the user typing "detach" just while some
thread is in the middle of an in-line step over. If that thread
belongs to the inferior that is being detached, then the step-over
never finishes, and threads of other inferiors are never re-resumed.
This fixes it.
Pedro Alves [Sun, 13 Dec 2020 01:35:05 +0000 (01:35 +0000)]
detach and breakpoint removal
A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process. That testcase sometimes fails with the inferior crashing
with SIGTRAP after the detach because of the bug fixed by this patch,
when tested with the native target.
The problem is that target_detach removes breakpoints from the target
immediately, and that does not work with the native GNU/Linux target
(and probably no other native target) currently. The test wouldn't
fail with this issue when testing against gdbserver, because gdbserver
does allow accessing memory while the current thread is running, by
transparently pausing all threads temporarily, without GDB noticing.
Implementing that in gdbserver was a lot of work, so I'm not looking
forward right now to do the same in the native target. Instead, I
came up with a simpler solution -- push the breakpoints removal down
to the targets. The Linux target conveniently already pauses all
threads before detaching them, since PTRACE_DETACH only works with
stopped threads, so we move removing breakpoints to after that. Only
the remote and GNU/Linux targets support support async execution, so
no other target should really need this.
gdb/ChangeLog:
* linux-nat.c (linux_nat_target::detach): Remove breakpoints
here...
* remote.c (remote_target::remote_detach_1): ... and here ...
* target.c (target_detach): ... instead of here.
Pedro Alves [Sun, 13 Dec 2020 01:35:05 +0000 (01:35 +0000)]
prepare_for_detach and ongoing displaced stepping
I noticed that "detach" while a program was running sometimes resulted
in the process crashing. I tracked it down to this change to
prepare_for_detach in commit 187b041e ("gdb: move displaced stepping
logic to gdbarch, allow starting concurrent displaced steps"):
/* Is any thread of this process displaced stepping? If not,
there's nothing else to do. */
- if (displaced->step_thread == nullptr)
+ if (displaced_step_in_progress (inf))
return;
The problem above is that the condition was inadvertently flipped. It
should have been:
if (!displaced_step_in_progress (inf))
So I fixed it, and wrote a testcase to exercise it. The testcase has
a number of threads constantly stepping over a breakpoint, and then
GDB detaches the process, while threads are running and stepping over
the breakpoint. And then I was surprised that my testcase would hang
-- GDB would get stuck in an infinite loop in prepare_for_detach,
here:
while (displaced_step_in_progress (inf))
{
...
What is going on is that since we now have two displaced stepping
buffers, as one displaced step finishes, GDB starts another, and
there's another one already in progress, and on and on, so the
displaced_step_in_progress condition never turns false. This happens
because we go via the whole handle_inferior_event, which tries to
start new step overs when one finishes. And also because while we
remove breakpoints from the target before prepare_for_detach is
called, handle_inferior_event ends up calling insert_breakpoints via
e.g. keep_going.
Thinking through all this, I came to the conclusion that going through
the whole handle_inferior_event isn't ideal. A _lot_ is done by that
function, e.g., some thread may get a signal which is passed to the
inferior, and gdb decides to try to get over the signal handler, which
reinstalls breakpoints. Or some process may exit. We can end up
reporting these events via normal_stop while detaching, maybe end up
running some breakpoint commands, or maybe even something runs an
inferior function call. Etc. All this after the user has already
declared they don't want to debug the process anymore, by asking to
detach.
I came to the conclusion that it's better to do the minimal amount of
work possible, in a more controlled fashion, without going through
handle_inferior_event. So in the new approach implemented by this
patch, if there are threads of the inferior that we're detaching in
the middle of a displaced step, stop them, and cancel the displaced
step. This is basically what stop_all_threads already does, via
wait_one and (the now factored out) handle_one, so I'm reusing those.
gdb/ChangeLog:
* infrun.c (struct wait_one_event): Move higher up.
(prepare_for_detach): Abort in-progress displaced steps instead of
letting them complete.
(handle_one): If the inferior is detaching, don't add the thread
back to the global step-over chain.
(restart_threads): Don't restart threads if detaching.
(handle_signal_stop): Remove inferior::detaching reference.
Pedro Alves [Mon, 11 Jan 2021 18:52:12 +0000 (18:52 +0000)]
prepare_for_detach: don't release scoped_restore at the end
After detaching from a process, the inf->detaching flag is
inadvertently left set to true. If you afterwards reuse the same
inferior to start a new process, GDB will mishave...
The problem is that prepare_for_detach discards the scoped_restore at
the end, while the intention is for the flag to be set only for the
duration of prepare_for_detach.
This was already a bug in the original commit that added
prepare_for_detach, commit 24291992dac3 ("PR gdb/11321"), by yours
truly. Back then, we still used cleanups, and the function called
discard_cleanups instead of do_cleanups, by mistake.
gdb/ChangeLog:
* infrun.c (prepare_for_detach): Don't release scoped_restore at
the end.
Pedro Alves [Mon, 11 Jan 2021 11:42:38 +0000 (11:42 +0000)]
gdbserver: spurious SIGTRAP w/ detach while step-over in progress
A following patch will add a new testcase that has two processes, each
with a number of threads constantly tripping a breakpoint and stepping
over it, because the breakpoint has a condition that evals false.
Then GDB detaches from one of the processes, while both processes are
running. And then the testcase sends a SIGUSR1 to the other process.
When run against gdbserver, that would occasionaly fail like this:
Thread 2.5 "detach-step-ove" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 208303.208305]
0x000055555555522a in thread_func (arg=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/detach-step-over.c:54
54 counter++; /* Set breakpoint here. */
Note that it's gdbserver itself that steps over the breakpoint.
The gdbserver logs reveal what happened:
- GDB manages to detach while a step over is in progress. That reaches
linux_process_target::complete_ongoing_step_over(), which does:
/* Passing NULL_PTID as filter indicates we want all events to
be left pending. Eventually this returns when there are no
unwaited-for children left. */
ret = wait_for_event_filtered (minus_one_ptid, null_ptid, &wstat,
__WALL);
As the comment say, this leaves all events pending, _including_ the
just finished step SIGTRAP. We never discard that SIGTRAP. So
GDBserver reports the SIGTRAP to GDB. GDB can't explain the
SIGTRAP, so it reports it to the user.
The gdbserver log looks like this. The LWP of interest is 208305:
Need step over [LWP 208305]? yes, found breakpoint at 0x555555555227
proceed_all_lwps: found thread 208305 needing a step-over
Starting step-over on LWP 208305. Stopping all threads
208305 starts a step-over.
>>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
stop_all_lwps (stop-and-suspend, except=LWP 208303.208305)
Sending sigstop to lwp 208303
Sending sigstop to lwp 207755
wait_for_sigstop: pulling events
LWFE: waitpid(-1, ...) returned 207755, ERRNO-OK
LLW: waitpid 207755 received Stopped (signal) (stopped)
pc is 0x7f7e045593bf
Expected stop.
LLW: SIGSTOP caught for LWP 207755.207755 while stopping threads.
LWFE: waitpid(-1, ...) returned 208303, ERRNO-OK
LLW: waitpid 208303 received Stopped (signal) (stopped)
pc is 0x7ffff7e743bf
Expected stop.
LLW: SIGSTOP caught for LWP 208303.208303 while stopping threads.
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
LLW: exit (no unwaited-for LWP)
stop_all_lwps done, setting stopping_threads back to !stopping
<<<< exiting void linux_process_target::stop_all_lwps(int, lwp_info*)
Done stopping all threads for step-over.
pc is 0x555555555227
Writing 8b to 0x555555555227 in process 208305
Could not findsigchld_handler
fast tracepoint jump at 0x555555555227 in list (uninserting).
pending reinsert at 0x555555555227
step from pc 0x555555555227
Resuming lwp 208305 (step, signal 0, stop expected)
<<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)
handling possible serial event
getpkt ("D;32b8b"); [no ack sent]
The detach request arrives.
sigchld_handler
Tracing is already off, ignoring
detach: step over in progress, finish it first
gdbserver realizes a step over for 208305 was in progress, let's it
finish.
LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
LLW: waitpid 208305 received Stopped (signal) (stopped)
pc is 0x555555555227
Expected stop.
LLW: step LWP 208303.208305, 0, 0 (discard delayed SIGSTOP)
pending reinsert at 0x555555555227
step from pc 0x555555555227
Resuming lwp 208305 (step, signal 0, stop not expected)
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
sigsuspend'ing
LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
LLW: waitpid 208305 received Trace/breakpoint trap (stopped)
pc is 0x55555555522a
CSBB: LWP 208303.208305 stopped by trace
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
LLW: exit (no unwaited-for LWP)
Finished step over.
The step-over for 208305 finishes.
Writing cc to 0x555555555227 in process 208305
Could not find fast tracepoint jump at 0x555555555227 in list (reinserting).
>>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
stop_all_lwps (stop, except=none)
wait_for_sigstop: pulling events
The detach proceeds (snipped).
...
proceed_one_lwp: lwp 208305
LWP 208305 has pending status, leaving stopped
Later on, 208305 has a pending status (the step SIGTRAP from the
step-over), so GDBserver starts the process of reporting it.
Pedro Alves [Wed, 6 Jan 2021 02:19:38 +0000 (02:19 +0000)]
Fix a couple vStopped pending ack bugs
A following patch will add a testcase that has two processes with
threads stepping over a breakpoint continuously, and then detaches
from one of the processes while threads are running. The other
process continues stepping over its breakpoint. And then the testcase
sends a SIGUSR1, expecting that GDB reports it. That would sometimes
hang against gdbserver, due to the bugs fixed here. Both bugs are
related, in that they're about remote protocol asynchronous Stop
notifications. There's a bug in GDB, and another in GDBserver.
The GDB bug:
- when we detach from a process, the remote target discards any
pending RSP notification related to that process, including the
in-flight, yet-unacked notification. Discarding the in-flight
notification is the problem. Until the in-flight notification is
acked with a vStopped packet, the server won't send another %Stop
notification. As a result, the debug session gets messed up. In
the new testcase's case, GDB would hang inside stop_all_threads,
waiting for a stop for one of the process'es threads, which never
arrived -- its stop reply was permanently stuck in the stop reply
queue, waiting for a vStopped packet that never arrived.
The GDBserver bug:
GDBserver has the opposite bug. It also discards notifications for
the process being detached. If that discards the head of the
notification queue, when gdb sends an ack, it ends up acking the
_next_ notification. Meaning, gdb loses one notification. In the
testcase, this results in a similar hang in stop_all_threads.
So we have two very similar bugs in GDB and GDBserver, both resulting
in a similar symptom. That's why I'm fixing them both at the same
time.
gdb/ChangeLog:
* remote.c (remote_notif_stop_ack): Don't error out on
TARGET_WAITKIND_IGNORE; instead, just ignore the notification.
(remote_target::discard_pending_stop_replies): Don't delete
in-flight notification; instead, clear its contents.
gdbserver/ChangeLog:
* server.cc (discard_queued_stop_replies): Don't ever discard the
notification at the head of the list.
Attaching to the hung GDB shows that GDB is busy in an infinite loop
in stop_all_threads:
(top-gdb) bt
#0 stop_all_threads () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:4755
#1 0x000055555597b424 in stop_waiting (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:7738
#2 0x0000555555976fba in handle_signal_stop (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5868
#3 0x0000555555975f6a in handle_inferior_event (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5527
#4 0x0000555555971da4 in fetch_inferior_event () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:3910
#5 0x00005555559540b2 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/pedro/gdb/binutils-gdb/src/gdb/inf-loop.c:42
#6 0x000055555597e825 in infrun_async_inferior_event_handler (data=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:9162
#7 0x0000555555687d1d in check_async_event_handlers () at /home/pedro/gdb/binutils-gdb/src/gdb/async-event.c:328
#8 0x0000555555e48284 in gdb_do_one_event () at /home/pedro/gdb/binutils-gdb/src/gdbsupport/event-loop.cc:216
#9 0x00005555559e7512 in start_event_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:347
#10 0x00005555559e765d in captured_command_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:407
#11 0x00005555559e8f80 in captured_main (data=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1239
#12 0x00005555559e8ff2 in gdb_main (args=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1254
#13 0x0000555555627c86 in main (argc=12, argv=0x7fffffffdc88) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:32
The problem is that the remote sends stops for all the threads:
But then wait_one never consumes them, always hitting this path:
4473 if (nfds == 0)
4474 {
4475 /* No waitable targets left. All must be stopped. */
4476 return {NULL, minus_one_ptid, {TARGET_WAITKIND_NO_RESUMED}};
4477 }
Resulting in GDB constanly calling target_stop to stop threads, but
the remote target never reporting back the stops to infrun.
That TARGET_WAITKIND_NO_RESUMED path shown above is always taken
because here, in wait_one too, just above:
The problem is that attaching installs an inferior continuation,
called when the target reports the initial attach stop, here, in
inf-loop.c:inferior_event_handler:
/* Do all continuations associated with the whole inferior (not
a particular thread). */
if (inferior_ptid != null_ptid)
do_all_inferior_continuations (0);
However, currently in non-stop mode, inferior_ptid is still null_ptid
when we get here.
If you try to do "set debug infrun 1" to debug the problem, however,
then the attach completes correctly, with GDB reporting a stop for
each thread.
The bug is that we're missing a switch_to_thread/context_switch call
when handling the initial stop, here:
Mike Frysinger [Wed, 30 Dec 2015 06:52:01 +0000 (01:52 -0500)]
sim: h8300: delete opcode caching
This is in preparation for converting h8300 over to the common memory
framework. It's not clear how much of a speed gain this was providing
in the first place -- a naive test of ~400k insns (using shlr.s) shows
that this code actually slowed things down a bit.
If anyone really cares about h8300 anymore, they can migrate to the
common insn caching logic.
Mike Frysinger [Wed, 30 Dec 2015 04:52:57 +0000 (23:52 -0500)]
gdb/sim: add support for exporting memory map
This allows gdb to quickly dump & process the memory map that the sim
knows about. This isn't fully accurate, but is largely limited by the
gdb memory map format. While the sim supports RWX bits, gdb can only
handle RW or RO regions.
Samuel Thibault [Thu, 7 Jan 2021 16:47:36 +0000 (16:47 +0000)]
libtool.m4: update GNU/Hurd test from upstream. In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. This backports it.
. * libtool.m4: Match gnu* along other GNU systems.
H.J. Lu [Thu, 7 Jan 2021 14:42:00 +0000 (06:42 -0800)]
ELF: Don't generate unused section symbols
For ELF targets, section symbols are required only for relocations.
With -ffunction-sections -fdata-sections, there can be many unused
section symbols. Sizes of libstdc++.a on Linux/x86-64 in GCC 11 are
With unused section symbols : 39411698 bytes
Without unused section symbols: 39227002 bytes
The unused section symbols in libstdc++.a occupy more than 180 KB.
Add BSF_SECTION_SYM_USED to indicate if a section symbol should be
included in the symbol table. The BSF_SECTION_SYM_USED should be set
if the section symbol is used for relocation or the section symbol is
always included in the symbol table.
Add keep_unused_section_symbols to bfd_target to indicate if unused
section symbols should be kept. If TARGET_KEEP_UNUSED_SECTION_SYMBOLS
is defined as FALSE, unused ection symbols will be removed.
Tested on Linux/x86. Other ELF backends need to:
1. Define TARGET_KEEP_UNUSED_SECTION_SYMBOLS to FALSE.
2. Mark used section symbols in assembler backend.
3. Remove unused section symbols from expected assembler and linker
outputs.
Tom Tromey [Thu, 7 Jan 2021 13:58:19 +0000 (06:58 -0700)]
Fix regression in Ada aggregate assignment
A recent upstream patch of mine caused a regression in aggregate
assignment. The bug was that add_component_interval didn't properly
update the array contents in one resize case.
I found furthermore that there was no test case that would provoke
this failure. This patch fixes the bug and introduces a test.
gdb/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
* ada-lang.c (add_component_interval): Start loop using vector's
updated size.
gdb/testsuite/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
Tom de Vries [Thu, 7 Jan 2021 09:37:51 +0000 (10:37 +0100)]
[gdb/build] Fix gdbserver build with -fsanitize=address
When doing a gdbserver build with CFLAGS/CXXFLAGS/LDFLAGS=-fsanitize=address
we run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o):
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
This started with commit 96648494173 "gdbsupport: make use of safe-ctype
functions from libiberty", which introduced a dependency of libinproctrace.so
on libiberty.
Fix this in gdbserver/Makefile.in by using a setup similar to what is done in
gcc-repo/src/libcc1/Makefile.am, such that ../libiberty/noasan/libiberty.a is
used instead.
Build on x86_64-linux, both with and without -fsanitize=address.
gdbserver/ChangeLog:
2021-01-07 Tom de Vries <tdevries@suse.de>
* Makefile.in (LIBIBERTY_NORMAL, LIBIBERTY_NOASAN, LIBIBERTY_PIC):
(LIBIBERTY_FOR_SHLIB): New var.
(LIBIBERTY): Set using $(LIBIBERTY_NORMAL).
(IPA_LIB): Use LIBIBERTY_FOR_SHLIB instead of LIBIBERTY in target rule.
Philipp Tomsich [Thu, 7 Jan 2021 07:53:25 +0000 (15:53 +0800)]
RISC-V: Add pause hint instruction.
Add support for the pause hint instruction, as specified in the
Zihintpause extension. The pause instruction is encoded as a
special form of a memory fence (which is available as part of the
base instruction set). The chosen encoding does not mandate any
particular memory ordering and therefore is a true hint.
bfd/
* elfxx-riscv.c (riscv_std_z_ext_strtab): Added zihintpause.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Added
INSN_CLASS_ZIHINTPAUSE.
* testsuite/gas/riscv/pause.d: New testcase. Adding coverage for
the pause hint instruction.
* testsuite/gas/riscv/pause.s: Likewise.
include/
* opcode/riscv-opc.h: Added MATCH_PAUSE, MASK_PAUSE and DECLARE_INSN
for pause hint instruction.
* opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZIHINTPAUSE.
opcodes/
* riscv-opc.c (riscv_opcodes): Add pause hint instruction.
Marcus Comstedt [Wed, 6 Jan 2021 10:36:54 +0000 (02:36 -0800)]
ld: xfail riscv64*-*-* for ld-scripts/empty-address-2 tests.
For now we have supported the riscv big endian targets, so
xfail riscv64*-*-* for ld-scripts/empty-address-2 tests, to
cover both little endian and big endian targets.
RISC-V: Support riscv bitmanip frozen ZBA/ZBB/ZBC instructions (v0.93).
In fact rev8/orc.b/zext.h are the aliases of grevi/gorci/pack[w], so we
should update them to INSN_ALIAS when we have supported their true instruction
in the future. Though we still use the [MATCH|MAKS]_[GREVI|GORCI|PACK|PACKW]
to encode them. Besides, the orc.b has the same encoding both in rv32 and
rv64, so we just keep one of them in the opcode table.
This patch is implemented according to the following link,
https://github.com/riscv/riscv-bitmanip/pull/101
2021-01-07 Claire Xenia Wolf <claire@symbioticeda.com>
Jim Wilson <jimw@sifive.com>
Andrew Waterman <andrew@sifive.com>
Maxim Blinov <maxim.blinov@embecosm.com>
Kito Cheng <kito.cheng@sifive.com>
Nelson Chu <nelson.chu@sifive.com>
bfd/
* elfxx-riscv.c (riscv_std_z_ext_strtab): Added zba, zbb and zbc.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZB*.
(riscv_get_default_ext_version): Do not check the default_isa_spec when
the version defined in the riscv_opcodes table is ISA_SPEC_CLASS_DRAFT.
* testsuite/gas/riscv/bitmanip-insns-32.d: New testcase.
* testsuite/gas/riscv/bitmanip-insns-64.d: Likewise.
* testsuite/gas/riscv/bitmanip-insns.s: Likewise.
include/
* opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for ZBA/ZBB/ZBC.
* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZB*.
(enum riscv_isa_spec_class): Added ISA_SPEC_CLASS_DRAFT for the
frozen extensions.
opcodes/
* riscv-opc.c (riscv_opcodes): Add ZBA/ZBB/ZBC instructions.
(MASK_RVB_IMM): Used for rev8 and orc.b encoding.
Alan Modra [Wed, 6 Jan 2021 22:03:56 +0000 (08:33 +1030)]
config.sub update broke powerpc-eabivle
$ ./config.sub powerpc-eabivle
Invalid configuration `powerpc-eabivle': OS `eabivle' not recognized
$ ./config.sub powerpc-unknown-eabivle
Invalid configuration `powerpc-unknown-eabivle': OS `eabivle' not recognized
Also powerpc-eabisim and probably some arm configurations.
Tom Tromey [Wed, 6 Jan 2021 20:47:48 +0000 (13:47 -0700)]
Fix fixed-point binary operation type handling
Testing showed that gdb was not correctly handling some fixed-point
binary operations correctly.
Addition and subtraction worked by casting the result to the type of
left hand operand. So, "fixed+int" had a different type -- and
different value -- from "int+fixed".
Furthermore, for multiplication and division, it does not make sense
to first cast both sides to the fixed-point type. For example, this
can prevent "f * 1" from yielding "f", if 1 is not in the domain of
"f". Instead, this patch changes gdb to use the value. (This is
somewhat different from Ada semantics, as those can yield a "universal
fixed point".)
This includes a new test case. It is only run in "minimal" mode, as
the old-style fixed point works differently, and is obsolete, so I
have no plans to change it.
gdb/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD, BINOP_SUB>:
Do not cast result.
* valarith.c (fixed_point_binop): Handle multiplication
and division specially.
* valops.c (value_to_gdb_mpq): New function.
(value_cast_to_fixed_point): Use it.
gdb/testsuite/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* gdb.ada/fixed_points/pck.ads (Delta4): New constant.
(FP4_Type): New type.
(FP4_Var): New variable.
* gdb.ada/fixed_points/fixed_points.adb: Update.
* gdb.ada/fixed_points.exp: Add tests for binary operators.
Simon Marchi [Wed, 6 Jan 2021 15:53:22 +0000 (10:53 -0500)]
gdb/testsuite: fix race in gdb.threads/signal-while-stepping-over-bp-other-thread.exp
Commit 3ec3145c5dd6 ("gdb: introduce scoped debug prints") updated some
tests using "set debug infrun" to handle the fact that a debug print is
now shown after the prompt, after an inferior stop. The same issue
happens in gdb.threads/signal-while-stepping-over-bp-other-thread.exp.
If I run it in a loop, it eventually fails like these other tests.
The problem is that the testsuite expects to see $gdb_prompt followed by
the end of the buffer. It happens that expect reads $gdb_prompt and the
debug print at the same time, in which case the regexp never matches and
we get a timeout.
The fix is the same as was done in 3ec3145c5dd6, make the testsuite
believe that the prompt is the standard GDB prompt followed by that
debug print.
Since that test uses gdb_test_sequence, and the expected prompt is in
gdb_test_sequence, add a -prompt switch to gdb_test_sequence to override
the prompt used for that call.
Alan Modra [Wed, 6 Jan 2021 01:31:10 +0000 (12:01 +1030)]
sparc-sun-solaris2 and sparc64-sun-solaris2 config
A bunch of ld tests fail on these targets due to the test specifying
-melf32_sparc or -melf64_sparc, which according to ld/configure.tgt
are valid. However, config.bfd lacks the corresponding bfd target
resulting in an error. Fix that by adding target_selvecs.
Marcus Comstedt [Tue, 5 Jan 2021 21:50:32 +0000 (22:50 +0100)]
RISC-V: Implement support for big endian targets.
RISC-V instruction/code is always little endian, but data might be
big-endian. Therefore, we can not use the original bfd_get/bfd_put
to get/put the code for big endian targets. Add new riscv_get_insn
and riscv_put_insn to always get/put code as little endian can resolve
the problem. Just remember to update them once we have supported
the 48-bit/128-bit instructions in the future patches.
bfd/
* config.bfd: Added targets riscv64be*-*-*, riscv32be*-*-* and
riscvbe*-*-*. Also added riscv_elf[32|64]_be_vec.
* configure.ac: Handle riscv_elf[32|64]_be_vec.
* configure: Regenerate.
* elfnn-riscv.c: Include <limits.h> and define CHAR_BIT for
riscv_is_insn_reloc.
(riscv_get_insn): RISC-V instructions are always little endian, but
bfd_get may be used for big-endian, so add new riscv_get_insn to handle
the insturctions.
(riscv_put_insn): Likewsie.
(riscv_is_insn_reloc): Check if we are relocaing an instruction.
(perform_relocation): Call riscv_is_insn_reloc to decide if we should
use riscv_[get|put]_insn or bfd_[get|put].
(riscv_zero_pcrel_hi_reloc): Use riscv_[get|put]_insn, bfd_[get|put]l32
or bfd_[get|put]l16 for code.
(riscv_elf_relocate_section): Likewise.
(riscv_elf_finish_dynamic_symbol): Likewise.
(riscv_elf_finish_dynamic_sections): Likewise.
(_bfd_riscv_relax_call): Likewise.
(_bfd_riscv_relax_lui): Likewise.
(_bfd_riscv_relax_align): Likewise.
(_bfd_riscv_relax_pc): Likewise.
(riscv_elf_object_p): Handled for big endian.
(TARGET_BIG_SYM, TARGET_BIG_NAME): Defined.
* targets.c: Add riscv_elf[32|64]_be_vec.
(_bfd_target_vector): Likewise.
gas/
* config/tc-riscv.c (riscv_target_format): Add elf64-bigriscv and
elf32-bigriscv.
(install_insn): Always write instructions as little endian.
(riscv_make_nops): Likewise.
(md_convert_frag_branch): Likewise.
(md_number_to_chars): Write data in target endianness.
(options, md_longopts): Add -mbig-endian and -mlittle-endian options.
(md_parse_option): Handle the endian options.
* config/tc-riscv.h: Only define TARGET_BYTES_BIG_ENDIAN if not
already defined.
* configure.tgt: Added riscv64be*, riscv32be*, riscvbe*.
Mike Frysinger [Tue, 5 Jan 2021 08:27:19 +0000 (03:27 -0500)]
sim: fr30: delete unused testsuite
Looking through the history, it doesn't seem like the fr30 port was
ever merged. There used to be a testsuite/fr30-elf/ dir, but that
was punted back in 2005 as being dead too. Since there's no refs
and the dir hasn't been touched since 1999, lets assume no one will
ever notice or care.
Mike Frysinger [Tue, 5 Jan 2021 05:22:28 +0000 (00:22 -0500)]
sim: h8300: fix test mach markers
These tests all fail to assemble when targeting the h8300 or h8300h
cpu variants with errors like:
rotl.s:242: Warning: Opcode `rotl.b' with these operand types not available in H8/300H mode
rotl.s:242: Error: invalid operands
It's been this way for years and no one seems to care, so disable
them for those targets since the assembler thinks it's impossible.
Mike Frysinger [Tue, 5 Jan 2021 05:19:33 +0000 (00:19 -0500)]
sim: h8300: simplify testsuite runner
We don't need to manually enumerate every test. Use a glob function
like every other port and rely on the (already existing) #mach headers
in each file to filter out targets we don't care about.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: fix lookups of pointers by name in parent dicts
When you look up a type by name using ctf_lookup_by_name, in most cases
libctf can just strip off any qualifiers and look for the name, but for
pointer types this doesn't work, since the caller will want the pointer
type itself. But pointer types are nameless, and while they cite the
types they point to, looking up a type by name requires a link going the
*other way*, from the type pointed to to the pointer type that points to
it.
libctf has always built this up at open time: ctf_ptrtab is an array of
type indexes pointing from the index of every type to the index of the
type that points to it. But because it is built up at open time (and
because it uses type indexes and not type IDs) it is restricted to
working within a single dict and ignoring parent/child
relationships. This is normally invisible, unless you manage to get a
dict with a type in the parent but the only pointer to it in a child.
The ctf_ptrtab will not track this relationship, so lookups of this
pointer type by name will fail. Since which type is in the parent and
which in the child is largely opaque to the user (which goes where is up
to the deduplicator, and it can and does reshuffle things to save
space), this leads to a very bad user experience, with an
obviously-visible pointer type which ctf_lookup_by_name claims doesn't
exist.
The fix is to have another array, ctf_pptrtab, which is populated in
child dicts: like the parent's ctf_ptrtab, it has one element per type
in the parent, but is all zeroes except for those types which are
pointed to by types in the child: so it maps parent dict indices to
child dict indices. The array is grown, and new child types scanned,
whenever a lookup happens and new types have been added to the child
since the last time a lookup happened that might need the pptrtab.
(So for non-writable dicts, this only happens once, since new types
cannot be added to non-writable dicts at all.)
Since this introduces new complexity (involving updating only part of
the ctf_pptrtab) which is only seen when a writable dict is in use, we
introduce a new libctf-writable testsuite that contains lookup tests
with no corresponding CTF-containing .c files (which can thus be run
even on platforms with no .ctf-section support in the linker yet), and
add a test to check that creation of pointers in children to types in
parents and a following lookup by name works as expected. The non-
writable case is tested in a new libctf-regression testsuite which is
used to track now-fixed outright bugs in libctf.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.h (ctf_dict_t) <ctf_pptrtab>: New.
<ctf_pptrtab_len>: New.
<ctf_pptrtab_typemax>: New.
* ctf-create.c (ctf_serialize): Update accordingly.
(ctf_add_reftype): Note that we don't need to update pptrtab here,
despite updating ptrtab.
* ctf-open.c (ctf_dict_close): Destroy the pptrtab.
(ctf_import): Likewise.
(ctf_import_unref): Likewise.
* ctf-lookup.c (grow_pptrtab): New.
(refresh_pptrtab): New, update a pptrtab.
(ctf_lookup_by_name): Turn into a wrapper around (and rename to)...
(ctf_lookup_by_name_internal): ... this: construct the pptrtab, and
use it in addition to the parent's ptrtab when parent dicts are
searched.
* testsuite/libctf-regression/regression.exp: New testsuite for
regression tests.
* testsuite/libctf-regression/pptrtab*: New test.
* testsuite/libctf-writable/writable.exp: New testsuite for tests of
writable CTF dicts.
* testsuite/libctf-writable/pptrtab*: New test.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: remove outdated comment about parent dict importing
Parent dicts are nowadays imported automatically in most situations, so
the comment in ctf_archive_iter warning people that they need to import
parents by hand is wrong. Remove it.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf, include: support unnamed structure members better
libctf has no intrinsic support for the GCC unnamed structure member
extension. This principally means that you can't look up named members
inside unnamed struct or union members via ctf_member_info: you have to
tiresomely find out the type ID of the unnamed members via iteration,
then look in each of these.
This is ridiculous. Fix it by extending ctf_member_info so that it
recurses into unnamed members for you: this is still unambiguous because
GCC won't let you create ambiguously-named members even in the presence
of this extension.
For consistency, and because the release hasn't happened and we can
still do this, break the ctf_member_next API and add flags: we specify
one flag, CTF_MN_RECURSE, which if set causes ctf_member_next to
automatically recurse into unnamed members for you, returning not only
the members themselves but all their contained members, so that you can
use ctf_member_next to identify every member that it would be valid to
call ctf_member_info with.
New lookup tests are added for all of this.
include/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.h (struct ctf_next) <u.ctn_next>: Move to...
<ctn_next>: ... here.
* ctf-util.c (ctf_next_destroy): Unconditionally destroy it.
* ctf-lookup.c (ctf_symbol_next): Adjust accordingly.
* ctf-types.c (ctf_member_iter): Reimplement in terms of...
(ctf_member_next): ... this. Support recursive unnamed member
iteration (off by default).
(ctf_member_info): Look up members in unnamed sub-structs.
* ctf-dedup.c (ctf_dedup_rhash_type): Adjust ctf_member_next call.
(ctf_dedup_emit_struct_members): Likewise.
* testsuite/libctf-lookup/struct-iteration-ctf.c: Test empty unnamed
members, and a normal member after the end.
* testsuite/libctf-lookup/struct-iteration.c: Verify that
ctf_member_count is consistent with the number of successful returns
from a non-recursive ctf_member_next.
* testsuite/libctf-lookup/struct-iteration-*: New, test iteration
over struct members.
* testsuite/libctf-lookup/struct-lookup.c: New test.
* testsuite/libctf-lookup/struct-lookup.lk: New test.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: warn about information loss because of unreleased format changes
In the last cycle there have been various changes that have replaced
parts of the CTF format with other parts without format
compatibility. This was not a compat break, because the old format was
never accepted by any version of libctf (the not-in-official-release CTF
compiler patch was emitting an invalid func info section), but
nonetheless it can confuse users using that patch if they link together
object files and find the func info sections in the inputs silently
disappearing.
Scan the linker inputs for this problem and emit a warning if any are
found.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-link.c (ctf_link_warn_outdated_inputs): New.
(ctf_link_write): Call it.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: new test of enum lookups with the _next iterator
I had reports that this doesn't work. This test shows it working (and
also shows how annoying it is to do symbol lookup by name with the
present API: we need a ctf_arc_lookup_symbol_name for users that don't
already have a symtab handy).
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* testsuite/libctf-lookup/enum-symbol.lk: New symbol-lookup test.
* testsuite/libctf-lookup/enum-symbol-ctf.c: New CTF input.
* testsuite/libctf-lookup/enum-symbol.c: New lookup test.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: new testsuite
This introduces a new lookup testsuite under libctf, which operates by
compiling (with libtool) a "lookup" .c file that uses libctf to analyze
some other program, then compiling some number of test object files with
CTF and optionally linking them together and running the lookup program
on the test object files (or linked test binary), before diffing the
result much as run_dump_test does.
This lets us test the portions of libctf that are not previously
testable, notably the portions that do lookup on linked output and
that create dynamic dictionaries and then do lookup on them before
writing them out, something that is not tested by the ld-ctf testsuite
because the linker never does this.
A couple of simple tests are added: one testing the functionality of
enum lookups, and one testing that the recently-added commit adding
extra paranoia to incomplete type handling doesn't break linking and
that the result of the link is an (otherwise-impossible) array of
forward type in the shared CTF dict.
ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* Makefile.def (libctf): No longer no_check. Checking depends on
all-ld.
* Makefile.in: Regenerated.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD
This complex morass inherited from libopcodes, which endeavours to
implement the effect of specifying ../bfd/libbfd.la in _LIBADD without
actually doing so, appears to be working around a libtool bug which as
far as I can see is no longer present (i.e., the install directory no
longer appears in -L arguments in libtool link-mode invocations, so
there is no danger of picking up old libbfds or other dependent
libraries).
Replaced with a simple reference to libbfd.la in the appropriate place.
Also adjusted things a little more so that libctf.la and libctf-nobfd.la
are self-contained, even when linking statically. This opens up the
possibility of running libtool to link against libctf from inside the
(upcoming) testsuite.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* configure.ac (BFD_LIBADD): Remove.
(BFD_DEPENDENCIES): Likewise. Remove associated cases.
(SHARED_LIBADD): Rename to...
(CTF_LIBADD): ... this. Stick in a suitable libiberty even when
linking statically.
* Makefile.am (libctf_nobfd_la_LIBADD): Adjust accordingly.
libctf uses libintl.
(libctf_la_LIBADD): Reference libbfd.la directly, not via
BFD_LIBADD.
(libctf_la_DEPENDENCIES): Remove.
* Makefile.in: Regenerate.
* configure: Likewise.
The first and last enumerands in the enumerated type are printed so that
you can tell if they've been cut off at one end or the other. (For now,
there is no way to control how many enumerands are printed.)
The dump output in general is improved, from this sort of thing a few
days ago:
4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4c) (kind 1) char:8 (aligned at 0x1, format 0x3, offset:bits 0x0:0x8)
4d: char * (size 0x8) -> 4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4d) (kind 3) char * (aligned at 0x8)
[...]
5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5a) (kind 6) struct _IO_FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
5b: __FILE (size 0xd8) -> 5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5b) (kind 10) __FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
[...]
406: struct coff_link_hash_entry (size 0x60)
[0x0] (ID 0x406) (kind 6) struct coff_link_hash_entry (aligned at 0x8)
[0x0] (ID 0x2b3) (kind 6) struct bfd_link_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d6) (kind 6) struct bfd_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d7) (kind 3) struct bfd_hash_entry * next (aligned at 0x8)
[0x40] (ID 0x61) (kind 3) const char * string (aligned at 0x8)
[0x80] (ID 0x1) (kind 1) long unsigned int hash:64 (aligned at 0x8, format 0x0, offset:bits 0x0:0x40)
[0xc0] (ID 0x397) (kind 8) enum bfd_link_hash_type type:8 (aligned at 0x1, format 0x0, offset:bits 0x0:0x8)
[0xc8] (ID 0x1c7) (kind 1) unsigned int non_ir_ref_regular:1 (aligned at 0x1, format 0x0, offset:bits 0x8:0x1)
[0xc9] (ID 0x1c8) (kind 1) unsigned int non_ir_ref_dynamic:1 (aligned at 0x1, format 0x0, offset:bits 0x9:0x1)
[0xca] (ID 0x1c9) (kind 1) unsigned int linker_def:1 (aligned at 0x1, format 0x0, offset:bits 0xa:0x1)
[0xcb] (ID 0x1ca) (kind 1) unsigned int ldscript_def:1 (aligned at 0x1, format 0x0, offset:bits 0xb:0x1)
[0xcc] (ID 0x1cb) (kind 1) unsigned int rel_from_abs:1 (aligned at 0x1, format 0x0, offset:bits 0xc:0x1)
... to this:
0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x4d: (kind 3) char * (size 0x8) (aligned at 0x8) -> 0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[0x0] _flags: ID 0x3: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
[0x40] _IO_read_ptr: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x80] _IO_read_end: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0xc0] _IO_read_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x100] _IO_write_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
0x5b: (kind 10) __FILE (size 0xd8) (aligned at 0x4) -> 0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[...]
0x406: (kind 6) struct coff_link_hash_entry (size 0x60) (aligned at 0x8)
[0x0] root: ID 0x2b3: (kind 6) struct bfd_link_hash_entry (size 0x38) (aligned at 0x8)
[0x0] root: ID 0x1d6: (kind 6) struct bfd_hash_entry (size 0x18) (aligned at 0x8)
[0x0] next: ID 0x1d7: (kind 3) struct bfd_hash_entry * (size 0x8) (aligned at 0x8)
[0x40] string: ID 0x61: (kind 3) const char * (size 0x8) (aligned at 0x8)
[0x80] hash: ID 0x1: (kind 1) long unsigned int (format 0x0) (size 0x8) (aligned at 0x8)
[0xc0] type: ID 0x397: (kind 8) enum bfd_link_hash_type (format 0x7f2e) (size 0x1) (aligned at 0x1)
[0xc8] non_ir_ref_regular: ID 0x1c7: (kind 1) unsigned int:1 [slice 0x8:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xc9] non_ir_ref_dynamic: ID 0x1c8: (kind 1) unsigned int:1 [slice 0x9:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xca] linker_def: ID 0x1c9: (kind 1) unsigned int:1 [slice 0xa:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcb] ldscript_def: ID 0x1ca: (kind 1) unsigned int:1 [slice 0xb:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcc] rel_from_abs: ID 0x1cb: (kind 1) unsigned int:1 [slice 0xc:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[...]
In particular, indented subsections are only present for actual structs
and unions, not forwards to them, and the structure itself doesn't add a
spurious level of indentation; structure field names are easier to spot
(at the cost of not making them look so much like C field declarations
any more, but they weren't always shown in valid decl syntax even before
this change) the size, type kind, and alignment are shown for all types
for which they are meaningful; bitfield info is only shown for actual
bitfields within structures and not ordinary integral fields; and type
IDs are never omitted. Type printing is in general much more consistent
and there is much less duplicated code in the type dumper.
There is one user-visible effect outside the dumper: ctf_type_(a)name
was erroneously emitting a trailing space on the name of slice types,
even though a slice of an int and an int with the corresponding encoding
represent the same type and should have the same print form. This
trailing space is now gone.
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-decl.c (ctf_decl_push): Exclude slices from the decl stack.
* ctf-types.c (ctf_type_aname): No longer deal with slices here.
* ctf-dump.c (ctf_dump_membstate_t) <cdm_toplevel_indent>: Constify.
(CTF_FT_REFS): New.
(CTF_FT_BITFIELD): Likewise.
(CTF_FT_ID): Likewise.
(ctf_dump_member): Do not do indentation here. Migrate the
type-printing parts of this into...
(ctf_dump_format_type): ... here, to be shared by all type printers.
Get the errno value for non-representable types right. Do not print
bitfield info for non-bitfields. Improve the format and indentation
of other type output. Shuffle spacing around to make all indentation
either 'width of column' or 4 chars.
(ctf_dump_label): Pass CTF_FT_REFS to ctf_dump_format_type.
(ctf_dump_objts): Likewise. Spacing shuffle.
(ctf_dump_var): Likewise.
(type_hex_digits): Migrate down in the file, to above its new user.
(ctf_dump_type): Indent here instead. Pass CTF_FT_REFS to
ctf_dump_format_type. Don't trim off excess linefeeds now we no
longer generate them. Dump enumerated types.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf, ld: prohibit getting the size or alignment of forwards
C allows you to do only a very few things with entities of incomplete
type (as opposed to pointers to them): make pointers to them and give
them cv-quals, roughly. In particular you can't sizeof them and you
can't get their alignment.
We cannot impose all the requirements the standard imposes on CTF users,
because the deduplicator can transform any structure type into a forward
for the purposes of breaking cycles: so CTF type graphs can easily
contain things like arrays of forward type (if you want to figure out
their size or alignment, you need to chase down the types this forward
might be a forward to in child TU dicts: we will soon add API functions
to make doing this much easier).
Nonetheless, it is still meaningless to ask for the size or alignment of
forwards: but libctf didn't prohibit this and returned nonsense from
internal implementation details when you asked (it returned the kind of
the pointed-to type as both the size and alignment, because forwards
reuse ctt_type as a type kind, and ctt_type and ctt_size overlap). So
introduce a new error, ECTF_INCOMPLETE, which is returned when you try
to get the size or alignment of forwards: we also return it when you try
to do things that require libctf itself to get the size or alignment of
a forward, notably using a forward as an array index type (which C
should never do in any case) or adding forwards to structures without
specifying their offset explicitly.
The dumper will not emit size or alignment info for forwards any more.
(This should not be an API break since ctf_type_size and ctf_type_align
could both return errors before now: any code that isn't expecting error
returns is already potentially broken.)
include/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Adjust for dumper
changes.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/forward.c: New test...
* testsuite/ld-ctf/forward.d: ... and results.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-types.c (ctf_type_resolve): Improve comment.
(ctf_type_size): Yield ECTF_INCOMPLETE when applied to forwards.
Emit errors into the right dict.
(ctf_type_align): Likewise.
* ctf-create.c (ctf_add_member_offset): Yield ECTF_INCOMPLETE
when adding a member without explicit offset when this member, or
the previous member, is incomplete.
* ctf-dump.c (ctf_dump_format_type): Do not try to print the size of
forwards.
(ctf_dump_member): Do not try to print their alignment.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf, ld: more dumper improvements
Dump more details about the types found in data object and function info
sections (the type ID and recursive info on the type itself, but not on
its members). Before now, this was being dumped for entries in the
variable section, but not for the closely-related function info and data
object sections, which is inconsistent and makes finding the
corresponding types in the type section unnecessarily hard. (This also
gets rid of code in which bugs have already been found in favour of the
same code everything else in the dumper uses to dump types.)
While we're doing that, change the recursive type dumper in question to
recursively dump info on arrays' element type, just as we do for all
types that reference other types. (Arrays are not a kind of reference
type in libctf, but perhaps we should change that in future and make
ctf_type_reference return the element type.)
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-dump.c (ctf_dump_objts): Dump by calling ctf_dump_format_type.
(ctf_dump_format_type): Don't emit the size for function objects.
Dump the element type of arrays like we dump the pointed-to type of
pointers, etc.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf, ld: CTF dumper changes for consistency
In most places in CTF dumper output, we emit 0x... for hex strings, but
in three places (top-level type IDs, string table offsets, and the file
magic number) we don't emit the 0x.
This is very confusing if by chance there are no hex digits in the
output. Add 0x consistently to everything, and adjust tests
accordingly. While we're at it, improve the indentation of the output
so that subsequent lines in aggregate output are indented by at least as
many columns as the colon in the type output. (Subsequent indentation
is still 4 spaces at a time.)
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-dump.c (ctf_dump_format_type): Add 0x to hex type IDs.
(ctf_dump_header): Add 0x to the hex magic number.
(ctf_dump_str): Add 0x to the hex string offsets.
(ctf_dump_membstate_t) <cdm_toplevel_indent>: New.
(ctf_dump_type): Adjust. Free it when we're done.
(type_hex_digits): New.
(ctf_dump_member): Align output depending on the width of the type
ID being generated. Use printf padding, not a loop, to generate
indentation.
Nick Alcock [Tue, 5 Jan 2021 13:25:56 +0000 (13:25 +0000)]
libctf: do not print array declarators backwards
The CTF declarator stack code (used by ctf_type_aname() and thus
ultimately by ctf-dump.c and objdump --ctf etc) contains careful
code to prepend array declarators to the stack it's building up
on the grounds that array declarators are ordered inside out: only
they're not, they're ordered outside in.
This has led to our (non-upstreamed) compiler emitting array declarators
backwards for years, because it looks backwards in the dumper unless
it's actually emitted backwards into the CTF so the dumper can wrongly
reverse it again: but
int[5][6]
should be an array of 6 int[5]s, not an array of 5 int[6]'s, so even if
the dumper gets it right, actual users calling ctf_array_info are going
to see a completely wrong type graph with the wrong bounds in it.
Fix trivial.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
Hannes Domani [Mon, 21 Dec 2020 13:26:29 +0000 (14:26 +0100)]
Prevent flickering when redrawing the TUI source window
tui_win_info::refresh_window simply calls wrefresh, which internally
does a doupdate.
This redraws the source background window without the source pad.
Then prefresh of the source pad draws the actual source code on top,
which flickers.
By changing this to wnoutrefresh, the actual drawing on the screen is
only done once in the following prefresh, without flickering.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-winsource.c (tui_source_window_base::refresh_window):
Call wnoutrefresh instead of tui_win_info::refresh_window.
Hannes Domani [Mon, 21 Dec 2020 12:52:03 +0000 (13:52 +0100)]
Redraw both spaces between line numbers and source code
There a 2 spaces between the numbers and source code, but only one of
them was redrawn.
So if you increase the source window height, the second space keeps the
character of the border rectangle.
With this both spaces are redrawn, so the border rectangle character is
overwritten.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-source.c (tui_source_window::show_line_number):
Redraw second space after line number.
Hannes Domani [Mon, 21 Dec 2020 12:16:24 +0000 (13:16 +0100)]
Fix TUI source window drawing
The smaxrow and smaxcol parameters of prefresh are the bottom right corner
of the text area inclusive, not exclusive.
And if the source window grows bigger in height, the pad has to grow as
well.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
PR tui/26927
* tui/tui-winsource.c (tui_source_window_base::refresh_window):
Fix source pad size in prefresh.
(tui_source_window_base::show_source_content): Grow source pad
if necessary.
Nelson Chu [Wed, 16 Dec 2020 03:03:34 +0000 (19:03 -0800)]
RISC-V: Ouput __global_pointer$ as dynamic symbol when generating dynamic PDE.
When the ifunc resolver is in the executable, we may relax the variables
to gp-relative access instruction in the ifunc resolver, or in other functions
that called by the ifunc resolver. But this will cause the uninitialized
gp problem since the ifunc need to be resolved at the early runtime, that
is at the pre-load stage, but we set the gp until the startup code.
At first, we try to add a new dynamic tag, DT_RISCV_GP, to stroe the gp value
and let ld.so can init the gp register early, before the pre-load stage. But
we need to extend the ABI if we want to add a new dynamic tag. Therefore,
in the psabi discussion, we try another solution, which was suggested by the
lld and FreeBSD linker experts, to let ld.so set the gp earlier - make sure
__global_pointer$ is output as a dynamic symbol when we are generating pde,
since we only do the relaxation for it. Afterwards, ld.so can search the
DT_SYMTAB to get the gp value, and set the gp register before resolving ifunc.
bfd/
* elfnn-riscv.c (allocate_dynrelocs): When we are generating pde, make
sure gp symbol is output as a dynamic symbol.
Mike Frysinger [Tue, 5 Jan 2021 01:17:37 +0000 (20:17 -0500)]
sim: include stdlib.h for atoi()
Make sure the files using atoi() include stdlib.h for its prototype.
These files were relying on it being included implicitly by others
which isn't guaranteed, and newer toolchains produce warnings.
Mike Frysinger [Tue, 5 Jan 2021 01:11:48 +0000 (20:11 -0500)]
sim: stdlib.h for abs()
Make sure the files using abs() include stdlib.h for its prototype.
These files were relying on it being included implicitly by others
which isn't guaranteed, and newer toolchains produce warnings.
Mike Frysinger [Sun, 3 Jan 2021 08:06:28 +0000 (03:06 -0500)]
sim: common: version: add build & homepage info when interactive
This mirrors gdb behavior of dumping extra info when being run in
interactive mode. It also gives us an excuse to use the otherwise
unused sim_print_config.
H.J. Lu [Mon, 4 Jan 2021 20:37:49 +0000 (12:37 -0800)]
elf: Allow mixed ordered/unordered inputs for non-relocatable link
For non-relocatable link with SHF_LINK_ORDER inputs, allow mixed indirect
and data inputs with ordered and unordered inputs:
1. Add pattern to bfd_section for the matching section name pattern in
linker script and update BFD_FAKE_SECTION.
2. Sort the consecutive bfd_indirect_link_order sections with the same
pattern to allow linker script to overdide input section order.
3. Place unordered sections before ordered sections.
4. Change the offsets of the indirect input sections only.
bfd/
PR ld/26256
* elflink.c (compare_link_order): Place unordered sections before
ordered sections.
(elf_fixup_link_order): Add a link info argument. Allow mixed
ordered and unordered input sections for non-relocatable link.
Sort the consecutive bfd_indirect_link_order sections with the
same pattern. Change the offsets of the bfd_indirect_link_order
sections only.
(bfd_elf_final_link): Pass info to elf_fixup_link_order.
* section.c (bfd_section): Add pattern.
(BFD_FAKE_SECTION): Initialize pattern to NULL.
* bfd-in2.h: Regenerated.
gas/
PR ld/26256
* config/obj-elf.c (obj_elf_change_section): Also filter out
SHF_LINK_ORDER.
While working on PR26935 I noticed that when running test-case
gdb.base/morestack.exp with target board unix/-m32/-fPIE/-pie and ld linker,
I get this linetable fragment for morestack.S using readelf -wL:
...
CU: ../../../../libgcc/config/i386/morestack.S:
Line number Starting address View Stmt
109 0xc9c x
...
838 0xe03 x
- 0xe04
636 0 x
637 0x3 x
- 0x4
...
but with "maint info line-table" I get:
...
INDEX LINE ADDRESS IS-STMT
0 END 0x00000004 Y
1 109 0x00000c9c Y
...
110 838 0x00000e03 Y
111 END 0x00000e04 Y
...
So, apparently the entries with addresses 0x0 and 0x3 are filtered out
because the addresses are out of range, but the same doesn't happen with the
end-of-seq terminator.
Fix this by filtering out end-of-seq terminators that do not actually
terminate anything.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-01-04 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::record_line): Filter out end-of-seq
terminators that do not terminate anything.
gdb/testsuite/ChangeLog:
2021-01-04 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: New file.
Simon Marchi [Mon, 4 Jan 2021 16:56:10 +0000 (11:56 -0500)]
gdb: introduce scoped debug prints
I spent a lot of time reading infrun debug logs recently, and I think
they could be made much more readable by being indented, to clearly see
what operation is done as part of what other operation. In the current
format, there are no visual cues to tell where things start and end,
it's just a big flat list. It's also difficult to understand what
caused a given operation (e.g. a call to resume_1) to be done.
To help with this, I propose to add the new scoped_debug_start_end
structure, along with a bunch of macros to make it convenient to use.
The idea of scoped_debug_start_end is simply to print a start and end
message at construction and destruction. It also increments/decrements
a depth counter in order to make debug statements printed during this
range use some indentation. Some care is taken to handle the fact that
debug can be turned on or off in the middle of such a range. For
example, a "set debug foo 1" command in a breakpoint command, or a
superior GDB manually changing the debug_foo variable.
Two macros are added in gdbsupport/common-debug.h, which are helpers to
define module-specific macros:
- scoped_debug_start_end: takes a message that is printed both at
construction / destruction, with "start: " and "end: " prefixes.
- scoped_debug_enter_exit: prints hard-coded "enter" and "exit"
messages, to denote the entry and exit of a function.
I added some examples in the infrun module to give an idea of how it can
be used and what the result looks like. The macros are in capital
letters (INFRUN_SCOPED_DEBUG_START_END and
INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but
that can be changed if you prefer something else.
Here's an excerpt of the debug
statements printed when doing "continue", where a displaced step is
started:
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 1
[infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd
[displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now
[displaced] prepare: selected buffer at 0x5555555550c2
[displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83
[displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2
[displaced] resume_1: run 0x5555555550c2: c7 45 fc 00
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed.
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296)
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300)
[infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed
[infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302)
[infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: exit
We can easily see where the call to `proceed` starts and end. We can
also see why there are a bunch of resume_1 calls, it's because we are
resuming threads, emulating all-stop on top of a non-stop target.
We also see that debug statements nest well with other modules that have
been migrated to use the "new" debug statement helpers (because they all
use debug_prefixed_vprintf in the end. I think this is desirable, for
example we could see the debug statements about reading the DWARF info
of a library nested under the debug statements about loading that
library.
Of course, modules that haven't been migrated to use the "new" helpers
will still print without indentations. This will be one good reason to
migrate them.
I think the runtime cost (when debug statements are disabled) of this is
reasonable, given the improvement in readability. There is the cost of
the conditionals (like standard debug statements), one more condition
(if (m_must_decrement_print_depth)) and the cost of constructing a stack
object, which means copying a fews pointers.
Adding the print in fetch_inferior_event breaks some tests that use "set
debug infrun", because it prints a debug statement after the prompt. I
adapted these tests to cope with it, by using the "-prompt" switch of
gdb_test_multiple to as if this debug statement is part of the expected
prompt. It's unfortunate that we have to do this, but I think the debug
print is useful, and I don't want a few tests to get in the way of
adding good debug output.
Simon Marchi [Mon, 4 Jan 2021 16:56:10 +0000 (11:56 -0500)]
gdb: use infrun_debug_printf in print_target_wait_results
The code in print_target_wait_results uses a single call to debug_printf
in order to make sure a single timestamp is emitted, despite printing
multiple lines. The result is:
I find this decision a bit counter productive, because it messes up the
alignment of the three lines. We don't care that three (slightly
different) timestamps are printed.
I suggest to change this function to use infrun_debug_printf, with this
result:
Note that the current code only prints the waiton_ptid as a string
between square brackets if pid != -1. I don't think this complexity is
needed in a debug print. I made it so it's always printed, which I
think results in a much simpler function.
gdb/ChangeLog:
* infrun.c (print_target_wait_results): Use infrun_debug_printf.
This is due to debug_prefixed_vprintf being implemented as three
separate calls to debug_printf / debug_vprintf. Each call gets its own
timestamp and newline, curtesy of vprintf_unfiltered.
My first idea was to add a "line_start" parameter to debug_vprintf,
allowing the caller to say whether the print is the start of the line.
A debug timestamp would only be printed if line_start was true.
However, that was much more invasive than the simple fix implemented in
this patch.
My second idea was to make debug_prefixed_vprintf use string_printf and
issue a single call to debug_printf. That would however prevent future
use of styling in the debug messages.
What is implemented in this patch is the same as is implemented in
GDBserver: the timestamp-printing code in GDB tracks whether the last
debug output ended with a newline. If so, it prints a timestamp on the
next debug output.
After the fix, it looks like this:
$ ./gdb -q -nx --data-directory=data-directory -ex "set debug infrun" -ex "set debug timestamp" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x1131: file test.c, line 2.
Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/a.out
941112.135662 [infrun] infrun_async: enable=1
941112.279930 [infrun] proceed: addr=0x7ffff7fd0100, signal=GDB_SIGNAL_0
941112.280064 [infrun] start_step_over: stealing global queue of threads to step, length = 0
941112.280125 [infrun] operator(): step-over queue now empty
941112.280194 [infrun] proceed: resuming process 646228
941112.280332 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [process 646228] at 0x7ffff7fd0100
941112.280480 [infrun] prepare_to_wait: prepare_to_wait
941112.281004 [infrun] target_wait (-1.0.0, status) =
[infrun] 646228.646228.0 [process 646228],
[infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP
941112.281078 [infrun] handle_inferior_event: status->kind = stopped, signal = GDB_SIGNAL_TRAP
gdb/ChangeLog:
* utils.c (vfprintf_unfiltered): Print timestamp only when
previous debug output ended with a newline.
Simon Marchi [Mon, 4 Jan 2021 16:43:59 +0000 (11:43 -0500)]
gdb/testsuite: avoid reading files through the remote protocol in gdb.server/*.exp
When I run some tests in gdb.server (fox example
gdb.server/ext-attach.exp) on Ubuntu 20.04 with separate debug info for
glibc installed, they often time out. This is because GDB reads the
debug info through the remote protocol which is particularly slow:
attach 316937
Attaching to program: /home/smarchi/build/binutils-gdb-all-targets/gdb/testsuite/outputs/gdb.server/ext-attach/ext-attach, process 316937
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...
Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
FAIL: gdb.server/ext-attach.exp: attach to remote program 1 (timeout)
This is avoided in gdbserver boards by adding "set sysroot" to GDBFLAGS
(see boards/local-board.exp), which makes GDB read files from the local
filesystem. But gdb.server tests spawn GDBserver directly, so are ran
even when using the default unix board, where the "set sysroot" isn't
used.
Modify these tests to append "set sysroot" to the GDBFLAGS, a bit like
lib/local-board.exp does.
One special case is gdb.server/sysroot.exp, whose intent is to test
different "set sysroot" values. For this one, increase the timeout when
testing the "target:" sysroot.
Simon Marchi [Mon, 4 Jan 2021 16:43:58 +0000 (11:43 -0500)]
gdb/testsuite: use clean_restart in gdb.server/ext-run.exp
I think the sequence of commands here could be replaced with
clean_restart. The test starts with GDB not started, so it should not
be started when we reach gdb_skip_xml_test.
Simon Marchi [Mon, 4 Jan 2021 16:43:58 +0000 (11:43 -0500)]
gdb/testsuite: use build_executable in gdb.server/stop-reply-no-thread.exp
This test uses prepare_for_testing, then does a clean_restart for each
test configuration. prepare_for_testing does a build_executable plus a
clean_restart. So the clean_restart inside prepare_for_testing is done
for nothing.
Change prepare_for_testing to just build_executable to avoid the
unnecessary clean_restart.
gdb/testsuite/ChangeLog:
* gdb.server/stop-reply-no-thread.exp: Use build_executable
instead of prepare_for_testing.
Simon Marchi [Mon, 4 Jan 2021 16:43:58 +0000 (11:43 -0500)]
gdb/testsuite: use clean_restart in gdb.server/solib-list.exp
I think this sequence of commands can be replaced by clean_restart,
despite what the comment says, as long as we don't use the `binfile`
argument to clean_restart.
Luis Machado [Tue, 22 Dec 2020 20:45:21 +0000 (17:45 -0300)]
Refactor struct trad_frame_saved_regs
The following patch drops the overloading going on with the trad_frame_saved_reg
struct and defines a new struct with a KIND enum and a union of different
fields.
The new struct looks like this:
struct trad_frame_saved_reg
{
setters/getters
...
private:
trad_frame_saved_reg_kind m_kind;
union {
LONGEST value;
int realreg;
LONGEST addr;
const gdb_byte *value_bytes;
} m_reg;
};
And the enums look like this:
/* Describes the kind of encoding a stored register has. */
enum class trad_frame_saved_reg_kind
{
/* Register value is unknown. */
UNKNOWN = 0,
/* Register value is a constant. */
VALUE,
/* Register value is in another register. */
REALREG,
/* Register value is at an address. */
ADDR,
/* Register value is a sequence of bytes. */
VALUE_BYTES
};
The patch also adds setters/getters and updates all the users of the old
struct.
It is worth mentioning that due to the previous overloaded nature of the
fields, some tdep files like to store negative offsets and indexes in the ADDR
field, so I kept the ADDR as LONGEST instead of CORE_ADDR. Those cases may
be better supported by a new enum entry.
I have not addressed those cases in this patch to prevent unwanted breakage,
given I have no way to test some of the targets. But it would be nice to
clean those up eventually.
The change to frame-unwind.* is to constify the parameter being passed to the
unwinding functions, given we now accept a "const gdb_byte *" for value bytes.
Tested on aarch64-linux/Ubuntu 20.04/18.04 and by building GDB with
--enable-targets=all.
gdb/ChangeLog:
2021-01-04 Luis Machado <luis.machado@linaro.org>
Update all users of trad_frame_saved_reg to use the new member
functions.
Remote all struct keywords from declarations of trad_frame_saved_reg
types, except on forward declarations.
When displaying ARM private file flag bits, use a 0x prefix.
* elf32-arm.c (elf32_arm_print_private_bfd_data): Prefix hex value
of private flags with 0x.
* elfnn-aarch64.c (elfNN_aarch64_print_private_bfd_data): Likewise.
projects / thirdparty / binutils-gdb.git / log
