Pedro Alves [Tue, 21 Jun 2022 17:05:19 +0000 (18:05 +0100)]
Cancel execution command on thread exit, when stepping, nexting, etc.
If your target has no support for TARGET_WAITKIND_NO_RESUMED events
(and no way to support them, such as the yet-unsubmitted AMDGPU
target), and you step over thread exit with scheduler-locking on, this
is what you get:
(gdb) n
[Thread ... exited]
*hang*
Getting back the prompt by typing Ctrl-C may not even work, since no
inferior thread is running to receive the SIGINT. Even if it works,
it seems unnecessarily harsh. If you started an execution command for
which there's a clear thread of interest (step, next, until, etc.),
and that thread disappears, then I think it's more user friendly if
GDB just detects the situation and aborts the command, giving back the
prompt.
That is what this commit implements. It does this by explicitly
requesting the target to report thread exit events whenever the main
resumed thread has a thread_fsm. Note that unlike stepping over a
breakpoint, we don't need to enable clone events in this case.
Pedro Alves [Tue, 21 Jun 2022 18:30:48 +0000 (19:30 +0100)]
Centralize "[Thread ...exited]" notifications
Currently, each target backend is responsible for printing "[Thread
...exited]" before deleting a thread. This leads to unnecessary
differences between targets, like e.g. with the remote target, we
never print such messages, even though we do print "[New Thread ...]".
E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
currently see:
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb)
Above, we only see "New Thread" notifications, even though threads
were deleted.
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb) q
This commit fixes this by moving the thread exit printing to common
code instead, triggered from within delete_thread (or rather,
set_thread_exited).
There's one wrinkle, though. While most targest want to print:
[Thread ... exited]
the Windows target wants to print:
[Thread ... exited with code <exit_code>]
... and sometimes wants to suppress the notification for the main
thread. To address that, this commits adds a delete_thread_with_code
function, only used by that target (so far).
Pedro Alves [Thu, 30 Jun 2022 12:04:07 +0000 (13:04 +0100)]
inferior::clear_thread_list always silent
Now that the MI mi_thread_exit observer ignores "silent", there's no
difference between inferior::clean_thread_list with silent true or
false. And for the CLI, clean_thread_list() never printed anything
either. So we can eliminate the 'silent' parameter.
Pedro Alves [Mon, 13 Jun 2022 18:26:59 +0000 (19:26 +0100)]
Document remote clone events, and QThreadOptions packet
This commit documents in both manual and NEWS:
- the new remote clone event stop reply,
- the new QThreadOptions packet and its current defined options,
- the associated "set/show remote thread-events-packet" command,
- and the associated QThreadOptions qSupported feature.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Ic1c8de1fefba95729bbd242969284265de42427e
Simon Marchi [Fri, 5 Feb 2021 21:42:32 +0000 (16:42 -0500)]
Testcases for stepping over thread exit syscall (PR gdb/27338)
- New in this series version:
- gdb.threads/step-over-thread-exit.exp has a couple new testing axes:
- non-stop vs all-stop.
- in non-stop have the testcase explicitly stop all threads in
non-stop mode, vs not doing that.
- bail out of gdb.threads/step-over-thread-exit.exp early on FAIL, to
avoid cascading timeouts.
Add new gdb.threads/step-over-thread-exit.exp and
gdb.threads/step-over-thread-exit-while-stop-all-threads.exp
testcases, exercising stepping over thread exit syscall. These make
use of lib/my-syscalls.S to define the exit syscall.
Co-authored-by: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9
Pedro Alves [Fri, 2 Jul 2021 10:46:40 +0000 (11:46 +0100)]
gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro
Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S
behind a SYSCALL macro so that it's easy to add new syscalls without
duplicating code.
Note that the way the macro is implemented, it only works correctly
for syscalls with up to 3 arguments, and, if the syscall doesn't
return (the macro doesn't bother to save/restore callee-saved
registers).
The following patch will want to use the macro to define a wrapper for
the "exit" syscall, so the limitations continue to be sufficient.
Pedro Alves [Tue, 7 Jun 2022 13:20:42 +0000 (14:20 +0100)]
Ignore failure to read PC when resuming
If GDB sets a GDB_THREAD_OPTION_EXIT option on a thread, and the
thread exits, the server reports the corresponding thread exit event,
and forgets about the thread, i.e., removes the exited thread from its
thread list.
On the GDB side, GDB set the GDB_THREAD_OPTION_EXIT option on a
thread, GDB delays deleting the thread from its thread list until it
sees the corresponding thread exit event, as that event needs special
handling in infrun.
When a thread disappears from the target, but it still exists on GDB's
thread list, in all-stop RSP mode, it can happen that GDB ends up
trying to resume such an already-exited-thread that GDB doesn't yet
know is gone. When that happens, against GDBserver, typically the
ongoing execution command fails with this error:
...
PC register is not available
(gdb)
At the remote protocol level, we may see e.g., this:
GDB saw an exit event for thread 619641.620754. After processing it,
infrun decides to re-resume the target again. To do that, infrun
picks some other thread that isn't exited yet from GDB's perspective,
switches to it, and calls keep_going. Below, infrun happens to pick
thread p97479.97479, the leader, which also exited, but GDB doesn't
know yet:
...
[remote] Sending packet: $Hgp97479.97479#75
[remote] Packet received: OK
[remote] Sending packet: $g#67
[remote] Packet received: xxxxxxxxxxxxxxxxx (...snip...) [1120 bytes omitted]
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target remote, no resumed threads
[infrun] fetch_inferior_event: exit
PC register is not available
(gdb)
The Linux backends, both in GDB and in GDBserver, already silently
ignore failures to resume, with the understanding that we'll see an
exit event soon. Core of GDB doesn't do that yet, though.
This patch is a small step in that direction. It swallows the error
when thrown from within resume_1. There are likely are spots where we
will need similar treatment, but we can tackle them as we find them.
After this patch, we'll see something like this instead:
Pedro Alves [Wed, 15 Jun 2022 12:19:47 +0000 (13:19 +0100)]
Report thread exit event for leader if reporting thread exit events
If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the
thread disappears from the thread list, GDB expects to shortly see a
thread exit event for it. See e.g., here, in
remote_target::update_thread_list():
/* Do not remove the thread if we've requested to be
notified of its exit. For example, the thread may be
displaced stepping, infrun will need to handle the
exit event, and displaced stepping info is recorded
in the thread object. If we deleted the thread now,
we'd lose that info. */
if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0)
continue;
There's one scenario that is deleting a thread from the
remote/gdbserver thread list without ever reporting a corresponding
thread exit event though -- check_zombie_leaders. This can lead to
GDB getting confused. For example, with a following patch that
enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see
this regression:
$ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp"
...
Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ...
FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)
... some more cascading FAILs ...
gdb.log shows:
(gdb) continue
Continuing.
FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)
A passing run would have resulted in:
(gdb) continue
Continuing.
No unwaited-for children left.
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
note how the leader thread is not listed in the remote-reported XML
thread list below:
(gdb) set debug remote 1
(gdb) set debug infrun 1
(gdb) info threads
Id Target Id Frame
* 1 Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65
3 Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39
(gdb) c
Continuing.
[infrun] clear_proceed_status_thread: 1163850.1163850.0
...
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f
[remote] Sending packet: $QPassSignals:#f3
[remote] Packet received: OK
[remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3
[remote] Packet received: OK
...
[infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3]
...
[infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0
[remote] Sending packet: $vCont;c:p11c24a.11c24a#98
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
[infrun] fetch_inferior_event: exit
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] random_pending_event_thread: None found.
[remote] wait: enter
[remote] Packet received: N
[remote] wait: exit
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: -1.0.0 [process -1],
[infrun] print_target_wait_results: status->kind = NO_RESUMED
[infrun] handle_inferior_event: status->kind = NO_RESUMED
[remote] Sending packet: $Hgp0.0#ad
[remote] Packet received: OK
[remote] Sending packet: $qXfer:threads:read::0,1000#92
[remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n
[infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
...
... however, infrun decided there was a resumed thread still, so
ignored the TARGET_WAITKIND_NO_RESUMED event. Debugging GDB, we see
that the "found resumed" thread that GDB finds, is the leader thread.
Even though that thread is not on the remote-reported thread list, it
is still on the GDB thread list, due to the special case in remote.c
mentioned above.
This commit addresses the issue by fixing GDBserver to report a thread
exit event for the zombie leader too, i.e., making GDBserver respect
the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit"
invariant. To do that, it takes a bit more code than one would
imagine off hand, due to the fact that we currently always report LWP
exit pending events as TARGET_WAITKIND_EXITED, and then decide whether
to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting
the event to GDBserver core. For the zombie leader scenario
described, we need to record early on that we want to report a
THREAD_EXITED event, and then make sure that decision isn't lost along
the way to reporting the event to GDBserver core.
Pedro Alves [Tue, 30 Nov 2021 19:52:11 +0000 (19:52 +0000)]
Don't resume new threads if scheduler-locking is in effect
If scheduler-locking is in effect, like e.g., with "set
scheduler-locking on", and you step over a function that spawns a new
thread, the new thread is allowed to run free, at least until some
event is hit, at which point, whether the new thread is re-resumed
depends on a number of seemingly random factors. E.g., if the target
is all-stop, and the parent thread hits a breakpoint, and gdb decides
the breakpoint isn't interesting to report to the user, then the
parent thread is resumed, but the new thread is left stopped.
I think that letting the new threads run with scheduler-locking
enabled is a defect. This commit fixes that, making use of the new
clone events on Linux, and of target_thread_events() on targets where
new threads have no connection to the thread that spawned them.
Testcase and documentation changes included.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
Pedro Alves [Fri, 22 Apr 2022 20:03:07 +0000 (21:03 +0100)]
gdbserver: Queue no-resumed event after thread exit
Normally, if the last thread resumed thread on the target exits, the
server sends a no-resumed event to GDB. If however, GDB enables the
GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the
server sends a thread exit event for that thread instead.
In all-stop RSP mode, since events can only be forwarded to GDB one at
a time, and the whole target stops whenever an event is reported, GDB
resumes the target again after getting a THREAD_EXITED event, and then
the server finally reports back a no-resumed event if/when
appropriate.
For non-stop RSP though, events are asynchronous, and if the server
sends a thread-exit event for the last resumed thread, the no-resumed
event is never sent. This patch makes sure that in non-stop mode, the
server queues a no-resumed event after the thread-exit event if it was
the last resumed thread that exited.
Without this, we'd see failures in step-over-thread-exit testcases
added later in the series, like so:
continue
Continuing.
- No unwaited-for children left.
- (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits
+ FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout)
Pedro Alves [Mon, 28 Jun 2021 13:05:54 +0000 (14:05 +0100)]
stop_all_threads: (re-)enable async before waiting for stops
Running the
gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcase
added later in the series against gdbserver, after the
TARGET_WAITKIND_NO_RESUMED fix from the following patch, would run
into an infinite loop in stop_all_threads, leading to a timeout:
FAIL: gdb.threads/step-over-thread-exit-while-stop-all-threads.exp: displaced-stepping=off: target-non-stop=on: iter 0: continue (timeout)
The is really a latent bug, and it is about the fact that
stop_all_threads stops listening to events from a target as soon as it
sees a TARGET_WAITKIND_NO_RESUMED, ignoring that
TARGET_WAITKIND_NO_RESUMED may be delayed. handle_no_resumed knows
how to handle delayed no-resumed events, but stop_all_threads was
never taught to.
In more detail, here's what happens with that testcase:
#1 - Multiple threads report breakpoint hits to gdb.
#2 - gdb picks one events, and it's for thread 1. All other stops are
left pending. thread 1 needs to move past a breakpoint, so gdb
stops all threads to start an inline step over for thread 1.
While stopping threads, some of the threads that were still
running report events that are also left pending.
#2 - gdb steps thread 1
#3 - Thread 1 exits while stepping (it steps over an exit syscall),
gdbserver reports thread exit for thread 1
#4 - Thread 1 was the last resumed thread, so gdbserver also reports
no-resumed:
[remote] Notification received: Stop:w0;p3445d0.3445d3
[remote] Sending packet: $vStopped#55
[remote] Packet received: N
[remote] Sending packet: $vStopped#55
[remote] Packet received: OK
#5 - gdb processes the thread exit for thread 1, finishes the step
over and restarts threads.
#6 - gdb picks the next event to process out of one of the resumed
threads with pending events:
[infrun] random_resumed_with_pending_wait_status: Found 32 events, selecting #11
#7 - This is again a breakpoint hit and the breakpoint needs to be
stepped over too, so gdb starts a step-over dance again.
#8 - We reach stop_all_threads, which finds that some threads need to
be stopped.
#9 - wait_one finally consumes the no-resumed event queue by #4.
Seeing this, wait_one disable target async, to stop listening for
events out of the remote target.
#10 - We still haven't seen all the stops expected, so
stop_all_threads tries another iteration.
#11 - Because the remote target is no longer async, and there are no
other targets, wait_one return no-resumed immediately without
polling the remote target.
#12 - We still haven't seen all the stops expected, so
stop_all_threads tries another iteration. goto #11, looping
forever.
Fix this by explicitly enabling/re-enabling target async on targets
that can async, before waiting for stops.
Pedro Alves [Fri, 5 Feb 2021 21:42:32 +0000 (16:42 -0500)]
gdb: clear step over information on thread exit (PR gdb/27338)
GDB doesn't handle correctly the case where a thread steps over a
breakpoint (using either in-line or displaced stepping), and the
executed instruction causes the thread to exit.
Using the test program included later in the series, this is what it
looks like with displaced-stepping, on x86-64 Linux, where we have two
displaced-step buffers:
$ ./gdb -q -nx --data-directory=data-directory build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit -ex "b my_exit_syscall" -ex r
Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[New Thread 0x7ffff7c5f640 (LWP 2915510)]
[Switching to Thread 0x7ffff7c5f640 (LWP 2915510)]
Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
68 syscall
(gdb) c
Continuing.
[New Thread 0x7ffff7c5f640 (LWP 2915524)]
[Thread 0x7ffff7c5f640 (LWP 2915510) exited]
[Switching to Thread 0x7ffff7c5f640 (LWP 2915524)]
Thread 3 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
68 syscall
(gdb) c
Continuing.
[New Thread 0x7ffff7c5f640 (LWP 2915616)]
[Thread 0x7ffff7c5f640 (LWP 2915524) exited]
[Switching to Thread 0x7ffff7c5f640 (LWP 2915616)]
Thread 4 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
68 syscall
(gdb) c
Continuing.
... hangs ...
The first two times we do "continue", we displaced-step the syscall
instruction that causes the thread to exit. When the thread exits,
the main thread, waiting on pthread_join, is unblocked. It spawns a
new thread, which hits the breakpoint on the syscall again. However,
infrun was never notified that the displaced-stepping threads are done
using the displaced-step buffer, so now both buffers are marked as
used. So when we do the third continue, there are no buffers
available to displaced-step the syscall, so the thread waits forever
for its turn.
When trying the same but with in-line step over (displaced-stepping
disabled):
$ ./gdb -q -nx --data-directory=data-directory \
build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit \
-ex "b my_exit_syscall" -ex "set displaced-stepping off" -ex r
Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[New Thread 0x7ffff7c5f640 (LWP 2928290)]
[Switching to Thread 0x7ffff7c5f640 (LWP 2928290)]
Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
68 syscall
(gdb) c
Continuing.
[Thread 0x7ffff7c5f640 (LWP 2928290) exited]
No unwaited-for children left.
(gdb) i th
Id Target Id Frame
1 Thread 0x7ffff7c60740 (LWP 2928285) "step-over-threa" 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0
The current thread <Thread ID 2> has terminated. See `help thread'.
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7c60740 (LWP 2928285))]
#0 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0
(gdb) c
Continuing.
^C^C
... hangs ...
The "continue" causes an in-line step to occur, meaning the main
thread is stopped while we step the syscall. The stepped thread exits
when executing the syscall, the linux-nat target notices there are no
more resumed threads to be waited for, so returns
TARGET_WAITKIND_NO_RESUMED, which causes the prompt to return. But
infrun never clears the in-line step over info. So if we try
continuing the main thread, GDB doesn't resume it, because it thinks
there's an in-line step in progress that we need to wait for to
finish, and we are stuck there.
To fix this, infrun needs to be informed when a thread doing a
displaced or in-line step over exits. We can do that with the new
target_set_thread_options mechanism which is optimal for only enabling
exit events of the thread that needs it; or, if that is not supported,
by using target_thread_events, which enables thread exit events for
all threads. This is done by this commit.
This patch then modifies handle_inferior_event in infrun.c to clean up
any step-over the exiting thread might have been doing at the time of
the exit. The cases to consider are:
- the exiting thread was doing an in-line step-over with an all-stop
target
- the exiting thread was doing an in-line step-over with a non-stop
target
- the exiting thread was doing a displaced step-over with a non-stop
target
The displaced-stepping buffer implementation in displaced-stepping.c
is modified to account for the fact that it's possible that we
"finish" a displaced step after a thread exit event. The buffer that
the exiting thread was using is marked as available again and the
original instructions under the scratch pad are restored. However, it
skips applying the fixup, which wouldn't make sense since the thread
does not exist anymore.
Another case that needs handling is if a displaced-stepping thread
exits, and the event is reported while we are in stop_all_threads. We
should call displaced_step_finish in the handle_one function, in that
case. It was already called in other code paths, just not the "thread
exited" path.
This commit doesn't make infrun ask the target to report the
TARGET_WAITKIND_THREAD_EXITED events yet, that'll be done later in the
series.
Note that "stop_print_frame = false;" line is moved to normal_stop,
because TARGET_WAITKIND_THREAD_EXITED can also end up with the event
transmorphed into TARGET_WAITKIND_NO_RESUMED. Moving it to
normal_stop keeps it centralized.
Co-authored-by: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
Change-Id: I745c6955d7ef90beb83bcf0ff1d1ac8b9b6285a5
When stepping over a breakpoint with displaced stepping, GDB needs to
be informed if the stepped thread exits, otherwise the displaced
stepping buffer that was allocated to that thread leaks, and this can
result in deadlock, with other threads waiting for their turn to
displaced step, but their turn never comes.
Similarly, when stepping over a breakpoint in line, GDB also needs to
be informed if the stepped thread exits, so that is can clear the step
over state and re-resume threads.
This commit makes it possible for GDB to ask the target to report
thread exit events for a given thread, using the new "thread options"
mechanism introduced by a previous patch.
This only adds the core bits. Following patches in the series will
teach the Linux backends (native & gdbserver) to handle the
GDB_THREAD_OPTION_EXIT option, and then a later patch will make use of
these thread exit events to clean up displaced stepping and inline
stepping state properly.
Pedro Alves [Mon, 5 Dec 2022 20:44:39 +0000 (20:44 +0000)]
Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to core
Currently, infrun assumes that when TARGET_WAITKIND_THREAD_EXITED is
reported, the corresponding GDB thread has already been removed from
the GDB thread list.
Later in the series, that will no longer work, as infrun will need to
refer to the thread's thread_info when it processes
TARGET_WAITKIND_THREAD_EXITED.
As preparation, this patch makes deleting the GDB thread
responsibility of infrun, instead of the target.
Pedro Alves [Tue, 5 Jul 2022 11:21:50 +0000 (12:21 +0100)]
gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE
gdbserver's linux_process_target::wait loops if called sync mode, and
wait_1 returns TARGET_WAITKIND_IGNORE, _and_ wait_1 also returns
null_ptid. The null_ptid check fails however when this path is taken:
Pedro Alves [Mon, 4 Apr 2022 20:12:03 +0000 (21:12 +0100)]
all-stop/synchronous RSP support thread-exit events
Currently, GDB does not understand the THREAD_EXITED stop reply in
remote all-stop mode. There's no good reason for this, it just
happened that THREAD_EXITED was only ever reported in non-stop mode so
far. This patch teaches GDB to parse that event in all-stop RSP too.
There is no need to add a qSupported feature for this, because the
server won't send a THREAD_EXITED event unless GDB explicitly asks for
it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT
QThreadOptions option added in the next patch.
Andrew Burgess [Wed, 30 Jun 2021 19:55:03 +0000 (20:55 +0100)]
Add test for stepping over clone syscall
- New in v3:
Addressed issue Tom de Vries ran into with no debug info for glibc.
- New in v2:
Fixed race, remove end anchor after prompt.
Fix leading anchor and inferior output flushing issue against
gdbserver.
Now works with displaced stepping.
Avoid printing inferior addresses in gdb.sum messages
Fail when clone child thread is stuck on scratchpad
Misc minor tweaks throughout.
This adds a new gdb.threads/stepi-over-clone.exp testcase, which
exercises stepping over a clone syscall, with displaced stepping vs
inline stepping, and all-stop vs non-stop. We already test stepping
over clone syscalls with gdb.base/step-over-syscall.exp, but this test
uses pthreads, while the other test uses raw clone, and this one is
more thorough.
Co-authored-by: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Change-Id: I95c06024736384ae8542a67ed9fdf6534c325c8e
Pedro Alves [Fri, 3 Dec 2021 22:10:05 +0000 (22:10 +0000)]
gdbserver: Hide and don't detach pending clone children
This commit extends the logic added by these two commits from a while
ago:
#1 7b961964f866 (gdbserver: hide fork child threads from GDB),
#2 df5ad102009c (gdb, gdbserver: detach fork child when detaching from fork parent)
... to handle thread clone events, which are very similar to (v)fork
events.
For #1, we want to hide clone children as well, so just update the
comments.
For #2, unlike (v)fork children, pending clone children aren't full
processes, they're just threads, so don't detach them in
handle_detach. linux-low.cc will take care of detaching them along
with all other threads of the process, there's nothing special that
needs to be done.
Pedro Alves [Tue, 23 Nov 2021 20:35:12 +0000 (20:35 +0000)]
Thread options & clone events (Linux GDBserver)
This patch teaches the Linux GDBserver backend to report clone events
to GDB, when GDB has requested them with the GDB_THREAD_OPTION_CLONE
thread option, via the new QThreadOptions packet.
This shuffles code in linux_process_target::handle_extended_wait
around to a more logical order when we now have to handle and
potentially report all of fork/vfork/clone.
Pedro Alves [Tue, 23 Nov 2021 20:35:12 +0000 (20:35 +0000)]
Thread options & clone events (native Linux)
This commit teaches the native Linux target about the
GDB_THREAD_OPTION_CLONE thread option. It's actually simpler to just
continue reporting all clone events unconditionally to the core.
There's never any harm in reporting a clone event when the option is
disabled. All we need to do is to report support for the option,
otherwise GDB falls back to use target_thread_events().
Pedro Alves [Tue, 23 Nov 2021 20:35:12 +0000 (20:35 +0000)]
Thread options & clone events (core + remote)
A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
event kind, and made the Linux target report clone events.
A following patch will teach Linux GDBserver to do the same thing.
However, for remote debugging, it wouldn't be ideal for GDBserver to
report every clone event to GDB, when GDB only cares about such events
in some specific situations. Reporting clone events all the time
would be potentially chatty. We don't enable thread create/exit
events all the time for the same reason. Instead we have the
QThreadEvents packet. QThreadEvents is target-wide, though.
This patch makes GDB instead explicitly request that the target
reports clone events or not, on a per-thread basis.
In order to be able to do that with GDBserver, we need a new remote
protocol feature. Since a following patch will want to enable thread
exit events on per-thread basis too, the packet introduced here is
more generic than just for clone events. It lets you enable/disable a
set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.
IOW, this commit introduces a new QThreadOptions packet, that lets you
specify a set of per-thread event options you want to enable. The
packet accepts a list of options/thread-id pairs, similarly to vCont,
processed left to right, with the options field being a number
interpreted as a bit mask of options. The only option defined in this
commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
to report clone events. Another patch later in the series will
introduce another option.
For example, this packet sets option "1" (clone events) on thread
p1000.2345:
QThreadOptions;1:p1000.2345
and this clears options for all threads of process 1000, and then sets
option "1" (clone events) on thread p1000.2345:
QThreadOptions;0:p1000.-1;1:p1000.2345
This clears options of all threads of all processes:
QThreadOptions;0
The target reports the set of supported options by including
"QThreadOptions=<supported options>" in its qSupported response.
infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
over a breakpoint.
Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
their parent's thread options. This is so that GDB can send e.g.,
"QThreadOptions;0;1:TID" without worrying about threads it doesn't
know about yet.
Documentation for this new remote protocol feature is included in a
documentation patch later in the series.
Pedro Alves [Tue, 25 Oct 2022 14:39:37 +0000 (15:39 +0100)]
enum_flags to_string
This commit introduces shared infrastructure that can be used to
implement enum_flags -> to_string functions. With this, if we want to
support converting a given enum_flags specialization to string, we
just need to implement a function that provides the enumerator->string
mapping, like so:
.. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like
"0x6 [SOME_FLAG2 SOME_FLAG3]".
If we happen to forget to update the mapping array when we introduce a
new enumerator, then the string representation will pretty-print the
flags it knows about, and then the leftover flags in hex (one single
number). For example, if we had missed mapping SOME_FLAG2 above, we'd
end up with:
Pedro Alves [Tue, 23 Nov 2021 20:35:12 +0000 (20:35 +0000)]
Support clone events in the remote protocol
The previous patch taught GDB about a new
TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target
report clone events.
A following patch will teach Linux GDBserver to do the same thing.
But before we get there, we need to teach the remote protocol about
TARGET_WAITKIND_THREAD_CLONED. That's what this patch does. Clone is
very similar to vfork and fork, and the new stop reply is likewise
handled similarly. The stub reports "T05clone:...".
GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and
forward it to GDB in this patch, but no backend actually emits it yet.
That will be done in a following patch.
Documentation for this new remote protocol feature is included in a
documentation patch later in the series.
Pedro Alves [Fri, 12 Nov 2021 20:50:29 +0000 (20:50 +0000)]
Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED
(A good chunk of the problem statement in the commit log below is
Andrew's, adjusted for a different solution, and for covering
displaced stepping too.)
This commit addresses bugs gdb/19675 and gdb/27830, which are about
stepping over a breakpoint set at a clone syscall instruction, one is
about displaced stepping, and the other about in-line stepping.
Currently, when a new thread is created through a clone syscall, GDB
sets the new thread running. With 'continue' this makes sense
(assuming no schedlock):
- all-stop mode, user issues 'continue', all threads are set running,
a newly created thread should also be set running.
- non-stop mode, user issues 'continue', other pre-existing threads
are not affected, but as the new thread is (sort-of) a child of the
thread the user asked to run, it makes sense that the new threads
should be created in the running state.
Similarly, if we are stopped at the clone syscall, and there's no
software breakpoint at this address, then the current behaviour is
fine:
- all-stop mode, user issues 'stepi', stepping will be done in place
(as there's no breakpoint to step over). While stepping the thread
of interest all the other threads will be allowed to continue. A
newly created thread will be set running, and then stopped once the
thread of interest has completed its step.
- non-stop mode, user issues 'stepi', stepping will be done in place
(as there's no breakpoint to step over). Other threads might be
running or stopped, but as with the continue case above, the new
thread will be created running. The only possible issue here is
that the new thread will be left running after the initial thread
has completed its stepi. The user would need to manually select
the thread and interrupt it, this might not be what the user
expects. However, this is not something this commit tries to
change.
The problem then is what happens when we try to step over a clone
syscall if there is a breakpoint at the syscall address.
- For both all-stop and non-stop modes, with in-line stepping:
+ user issues 'stepi',
+ [non-stop mode only] GDB stops all threads. In all-stop mode all
threads are already stopped.
+ GDB removes s/w breakpoint at syscall address,
+ GDB single steps just the thread of interest, all other threads
are left stopped,
+ New thread is created running,
+ Initial thread completes its step,
+ [non-stop mode only] GDB resumes all threads that it previously
stopped.
There are two problems in the in-line stepping scenario above:
1. The new thread might pass through the same code that the initial
thread is in (i.e. the clone syscall code), in which case it will
fail to hit the breakpoint in clone as this was removed so the
first thread can single step,
2. The new thread might trigger some other stop event before the
initial thread reports its step completion. If this happens we
end up triggering an assertion as GDB assumes that only the
thread being stepped should stop. The assert looks like this:
infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
- For both all-stop and non-stop modes, with displaced stepping:
+ user issues 'stepi',
+ GDB starts the displaced step, moves thread's PC to the
out-of-line scratch pad, maybe adjusts registers,
+ GDB single steps the thread of interest, [non-stop mode only] all
other threads are left as they were, either running or stopped.
In all-stop, all other threads are left stopped.
+ New thread is created running,
+ Initial thread completes its step, GDB re-adjusts its PC,
restores/releases scratchpad,
+ [non-stop mode only] GDB resumes the thread, now past its
breakpoint.
+ [all-stop mode only] GDB resumes all threads.
There is one problem with the displaced stepping scenario above:
3. When the parent thread completed its step, GDB adjusted its PC,
but did not adjust the child's PC, thus that new child thread
will continue execution in the scratch pad, invoking undefined
behavior. If you're lucky, you see a crash. If unlucky, the
inferior gets silently corrupted.
What is needed is for GDB to have more control over whether the new
thread is created running or not. Issue #1 above requires that the
new thread not be allowed to run until the breakpoint has been
reinserted. The only way to guarantee this is if the new thread is
held in a stopped state until the single step has completed. Issue #3
above requires that GDB is informed of when a thread clones itself,
and of what is the child's ptid, so that GDB can fixup both the parent
and the child.
When looking for solutions to this problem I considered how GDB
handles fork/vfork as these have some of the same issues. The main
difference between fork/vfork and clone is that the clone events are
not reported back to core GDB. Instead, the clone event is handled
automatically in the target code and the child thread is immediately
set running.
Note we have support for requesting thread creation events out of the
target (TARGET_WAITKIND_THREAD_CREATED). However, those are reported
for the new/child thread. That would be sufficient to address in-line
stepping (issue #1), but not for displaced-stepping (issue #3). To
handle displaced-stepping, we need an event that is reported to the
_parent_ of the clone, as the information about the displaced step is
associated with the clone parent. TARGET_WAITKIND_THREAD_CREATED
includes no indication of which thread is the parent that spawned the
new child. In fact, for some targets, like e.g., Windows, it would be
impossible to know which thread that was, as thread creation there
doesn't work by "cloning".
The solution implemented here is to model clone on fork/vfork, and
introduce a new TARGET_WAITKIND_THREAD_CLONED event. This event is
similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except
that we end up with a new thread in the same process, instead of a new
thread of a new process. Like FORKED and VFORKED, THREAD_CLONED
waitstatuses have a child_ptid property, and the child is held stopped
until GDB explicitly resumes it. This addresses the in-line stepping
case (issues #1 and #2).
The infrun code that handles displaced stepping fixup for the child
after a fork/vfork event is thus reused for THREAD_CLONE, with some
minimal conditions added, addressing the displaced stepping case
(issue #3).
The native Linux backend is adjusted to unconditionally report
TARGET_WAITKIND_THREAD_CLONED events to the core.
Following the follow_fork model in core GDB, we introduce a
target_follow_clone target method, which is responsible for making the
new clone child visible to the rest of GDB.
Subsequent patches will add clone events support to the remote
protocol and gdbserver.
A testcase will be added by a later patch.
displaced_step_in_progress_thread becomes unused with this patch, but
a new use will reappear later in the series. To avoid deleting it and
readding it back, this patch marks it with attribute unused, and the
latter patch removes the attribute again. We need to do this because
the function is static, and with no callers, the compiler would warn,
(error with -Werror), breaking the build.
Pedro Alves [Wed, 13 Jul 2022 16:16:38 +0000 (17:16 +0100)]
gdb/linux: Delete all other LWPs immediately on ptrace exec event
I noticed that after a following patch ("Step over clone syscall w/
breakpoint, TARGET_WAITKIND_THREAD_CLONED"), the
gdb.threads/step-over-exec.exp was passing cleanly, but still, we'd
end up with four new unexpected GDB core dumps:
=== gdb Summary ===
# of unexpected core files 4
# of expected passes 48
That said patch is making the pre-existing
gdb.threads/step-over-exec.exp testcase (almost silently) expose a
latent problem in gdb/linux-nat.c, resulting in a GDB crash when:
#1 - a non-leader thread execs
#2 - the post-exec program stops somewhere
#3 - you kill the inferior
Instead of #3 directly, the testcase just returns, which ends up in
gdb_exit, tearing down GDB, which kills the inferior, and is thus
equivalent to #3 above.
Vis:
$ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true
...
(top-gdb) r
...
(gdb) b main
...
(gdb) r
...
Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69
69 argv0 = argv[0];
(gdb) c
Continuing.
[New Thread 0x7ffff7d89700 (LWP 2506975)]
Other going in exec.
Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28
28 foo ();
(gdb) k
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
393 return m_suspend.waitstatus_pending_p;
(top-gdb) bt
#0 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
#1 0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345
#2 0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564
#3 0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284
#4 0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278
#5 0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247
#6 0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864
#7 0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590
#8 0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911
...
The root of the problem is that when a non-leader LWP execs, it just
changes its tid to the tgid, replacing the pre-exec leader thread,
becoming the new leader. There's no thread exit event for the execing
thread. It's as if the old pre-exec LWP vanishes without trace. The
ptrace man page says:
"PTRACE_O_TRACEEXEC (since Linux 2.5.46)
Stop the tracee at the next execve(2). A waitpid(2) by the
tracer will return a status value such that
status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))
If the execing thread is not a thread group leader, the thread
ID is reset to thread group leader's ID before this stop.
Since Linux 3.0, the former thread ID can be retrieved with
PTRACE_GETEVENTMSG."
When the core of GDB processes an exec events, it deletes all the
threads of the inferior. But, that is too late -- deleting the thread
does not delete the corresponding LWP, so we end leaving the pre-exec
non-leader LWP stale in the LWP list. That's what leads to the crash
above -- linux_nat_target::kill iterates over all LWPs, and after the
patch in question, that code will look for the corresponding
thread_info for each LWP. For the pre-exec non-leader LWP still
listed, won't find one.
This patch fixes it, by deleting the pre-exec non-leader LWP (and
thread) from the LWP/thread lists as soon as we get an exec event out
of ptrace.
GDBserver does not need an equivalent fix, because it is already doing
this, as side effect of mourning the pre-exec process, in
gdbserver/linux-low.cc:
else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events)
{
...
/* Delete the execing process and all its threads. */
mourn (proc);
switch_to_thread (nullptr);
Pedro Alves [Fri, 12 Nov 2021 20:50:29 +0000 (20:50 +0000)]
linux-nat: introduce pending_status_str
I noticed that some debug log output printing an lwp's pending status
wasn't considering lp->waitstatus. This fixes it, by introducing a
new pending_status_str function.
Pedro Alves [Tue, 22 Jun 2021 14:42:51 +0000 (15:42 +0100)]
displaced step: pass down target_waitstatus instead of gdb_signal
This commit tweaks displaced_step_finish & friends to pass down a
target_waitstatus instead of a gdb_signal. This needed because a
patch later in the series will want to make
displaced_step_buffers::finish handle TARGET_WAITKIND_THREAD_EXITED.
It also helps with the TARGET_WAITKIND_THREAD_CLONED patch.
Pedro Alves [Fri, 25 Nov 2022 16:20:22 +0000 (16:20 +0000)]
all-stop "follow-fork parent" and selecting another thread
With:
- catch a fork in thread 1
- select thread 2
- set follow-fork child
- next
... follow_fork notices that thread 1 had last stopped for a fork
which hasn't been followed yet, and because thread 1 is not the
current thread, GDB aborts the execution command, presenting the stop
in thread 1.
That makes sense, as only the forking thread (thread 1) survives in
the child, so better stop and let the user decide how to proceed.
However, with:
- catch a fork in thread 1
- select thread 2
- set follow-fork parent << note difference here
- next
... GDB does the same: follow_fork notices that thread 1 had last
stopped for a fork which hasn't been followed yet, and because thread
1 is not the current thread, GDB aborts the execution command,
presenting the stop in thread 1.
Aborting/stopping in this case doesn't make sense to me. As we're
following the parent, thread 2 will still continue to exist in the
parent. What the child does after we've followed the parent shouldn't
matter -- it can go on running free, be detached, etc., depending on
"set schedule-multiple", "set detach-on-fork", etc. That does not
influence the execution command that the user issued for the parent
thread.
So this patch changes GDB in that direction -- in follow_fork, if
following the parent, and we've switched threads meanwhile, switch
back to the unfollowed thread, follow it (stay with the parent), and
don't abort/stop. If we're following a fork (as opposed to vfork),
then switch back again to the thread that the user was trying to
resume. If following a vfork, however, stay with the vforking-thread
selected, as we will need to see a vfork_done event first, before we
can resume any other thread.
As I was working on this, I managed to end up calling target_resume
for a solo-thread resume (to collect the vfork_done event), with
scope_ptid pointing at the vfork parent thread, and inferior_ptid
pointing to the vfork child. For a solo-thread resume, the scope_ptid
argument to target_resume must the same as inferior_ptid. The mistake
was caught by the assertion in target_resume, like so:
Pedro Alves [Thu, 17 Nov 2022 18:25:36 +0000 (18:25 +0000)]
Make follow_fork not rely on get_last_target_status
Currently, if
- you're in all-stop mode,
- the inferior last stopped because of a fork catchpoint,
when you next resume the program, gdb checks whether it had last
stopped for a fork/vfork, and if so,
a) if the current thread is the one that forked, gdb follows the
parent/child, depending on "set follow-fork" mode.
b) if the current thread is some other thread (because you switched
threads meanwhile), gdb switches back to that thread, gdb follows
the parent/child, and stops the resumption command.
There's a problem in b), however -- if you have "set schedule-multiple
off", which is the default, or "set scheduler-locking on", gdb will
still switch back to the forking thread, even if you didn't want to
resume it. For example, with:
(gdb) catch fork
(gdb) c
* thread 1 stops for fork
(gdb) thread 2
(gdb) set scheduler-locking on
(gdb) c
gdb switches back to thread 1, and follows the fork.
Or with:
(gdb) add-inferior -exec prog
(gdb) inferior 2
(gdb) start
(gdb) inferior 1
(gdb) catch fork
(gdb) c
* thread 1.1 stops for fork
(gdb) inferior 2
(gdb) set schedule-multiple off # this is the default
(gdb) c
gdb switches back to thread 1.1, and follows the fork.
Another issue is that, because follow_fork relies on
get_last_target_status to find the thread that has a pending fork, it
is possible to confuse it. For example, "run" or "start" call
init_wait_for_inferior, which clears the last target status, so this:
(gdb) catch fork
(gdb) c
* thread 1 stops for fork
(gdb) add-inferior -exec prog
(gdb) inferior 2
(gdb) start
(gdb) set follow-fork child
(gdb) inferior 1
(gdb) n
... does not follow to the fork child of inferior 1, because the
get_last_target_status call in follow_fork doesn't return a
TARGET_WAITKIND_FORKED. Thanks to Simon for this example.
All of the above are fixed by this patch. It changes follow_fork to
not look at get_last_target_status, but to instead iterate over the
set of threads that the user is resuming, and find the one that has a
pending_follow kind of fork/vfork.
gdb.base/foll-fork.exp is augmented to exercise the last "start"
scenario described above. The other cases will be exercised in the
testcase added by the following patch.
Pedro Alves [Thu, 17 Nov 2022 23:21:04 +0000 (23:21 +0000)]
Improve "info program"
With gdb.base/catch-follow-exec.exp, we currently see:
~~~~~~~~~~~~~~~
(gdb)
continue
Continuing.
process 693251 is executing new program: /usr/bin/ls
[New inferior 2]
[New process 693251]
[Switching to process 693251]
Thread 2.1 "ls" hit Catchpoint 2 (exec'd /usr/bin/ls), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb)
info prog
No selected thread.
~~~~~~~~~~~~~~~
Note the "No selected thread" output. That is totally bogus, because
there _is_ a selected thread. What GDB really means, is that it can't
find the thread that had the latest (user-visible) stop. And that
happens because "info program" gets that info from
get_last_target_status, and the last target status has been cleared.
However, GDB also checks if there is a selected thread, here:
.. the null_ptid part. That is also bogus, because what matters is
the thread that last reported a stop, not the current thread:
- in all-stop mode, "info program" displays info about the last stop.
That may have happened on a thread different from the selected
thread.
- in non-stop mode, because all threads are controlled individually,
"info program" shows info about the last stop of the selected
thread.
The current code already behaves this way, though in a poor way. This
patch reimplements it, such that the all-stop version now finds the
thread that last reported an event via the 'previous_thread' strong
reference. Being a strong reference means that if that thread has
exited since the event was reported, 'previous_thread' will still
point to it, so we can say that the thread exited meanwhile.
The patch also extends "info program" output a little, to let the user
know which thread we are printing info for. For example, for the
gdb.base/catch-follow-exec.exp case we shown above, we now get:
(gdb) info prog
Last stopped for thread 2.1 (process 710867).
Using the running image of child process 710867.
Program stopped at 0x7ffff7fd0100.
It stopped at breakpoint 2.
Type "info stack" or "info registers" for more information.
(gdb)
while in non-stop mode, we get:
(gdb) info prog
Selected thread 2.1 (process 710867).
Using the running image of child process 710867.
Program stopped at 0x7ffff7fd0100.
It stopped at breakpoint 2.
Type "info stack" or "info registers" for more information.
(gdb)
In both cases, the first line of output is new.
The existing code considered these running/exited cases as an error,
but I think that that's incorrect, since this is IMO just plain
execution info as well. So the patch makes those cases regular
prints, not errors.
If the thread is running, we get, in non-stop mode:
(gdb) info prog
Selected thread 2.1 (process 710867).
Selected thread is running.
... and in all-stop:
(gdb) info prog
Last stopped for thread 2.1 (process 710867).
Thread is now running.
If the thread has exited, we get, in non-stop mode:
(gdb) info prog
Selected thread 2.1 (process 710867).
Selected thread has exited.
... and in all-stop:
(gdb) info prog
Last stopped for thread 2.1 (process 710867).
Thread has since exited.
The gdb.base/info-program.exp testcase was much extended to test
all-stop/non-stop and single-threaded/multi-threaded.
Pedro Alves [Thu, 17 Nov 2022 23:08:58 +0000 (23:08 +0000)]
Convert previous_inferior_ptid to strong reference to thread_info
I originally wrote this patch, because while working on some other
patch, I spotted a regression in the
gdb.multi/multi-target-no-resumed.exp.exp testcase. Debugging the
issue, I realized that the problem was related to how I was using
previous_inferior_ptid to look up the thread the user had last
selected. The problem is that previous_inferior_ptid alone doesn't
tell you which target that ptid is from, and I was just always using
the current target, which was incorrect. Two different targets may
have threads with the same ptid.
I decided to fix this by replacing previous_inferior_ptid with a
strong reference to the thread, called previous_thread.
I have since found a new motivation for this change -- I would like to
tweak "info program" to not rely on get_last_target_status returning a
ptid that still exists in the thread list. With both the follow_fork
changes later in this series, and the step-over-thread-exit changes,
that can happen, as we'll delete threads and not clear the last
waitstatus.
A new update_previous_thread function is added that can be used to
update previous_thread from inferior_ptid. This must be called in
several places that really want to get rid of previous_thread thread,
and reset the thread id counter, otherwise we get regressions like
these:
(gdb) info threads -gid
Id GId Target Id Frame
- * 1 1 Thread 2974541.2974541 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
- (gdb) PASS: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid
+ * 1 2 Thread 2958361.2958361 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
+ (gdb) FAIL: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid
and:
Core was generated by `build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/si'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
398 kill (getpid (), SIGABRT);
+[Current thread is 1 (LWP 2662066)]
Restored records from core file build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/sigall.precsave.
#0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
398 kill (getpid (), SIGABRT);
continue
Continuing.
-Program received signal SIGABRT, Aborted.
+Thread 1 received signal SIGABRT, Aborted.
0x00007ffff7dfd55b in kill () at ../sysdeps/unix/syscall-template.S:78
78 ../sysdeps/unix/syscall-template.S: No such file or directory.
-(gdb) PASS: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT
+(gdb) FAIL: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT
I.e., GDB was failing to restart the thread counter back to 1, because
the previous_thread thread was being help due to the strong reference.
Tested on GNU/Linux native, gdbserver and gdbserver + "maint set
target-non-stop on".
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
Pedro Alves [Sat, 3 Dec 2022 16:20:51 +0000 (16:20 +0000)]
Tweak "Using the running image of ..." output
Currently, "info files" and "info program" on a few native targets
show:
(gdb) info files
Symbols from "/home/pedro/gdb/tests/threads".
Native process:
Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
(gdb) info program
Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Program stopped at 0x555555555278.
...
This patch changes them to:
(gdb) info files
Symbols from "/home/pedro/gdb/tests/threads".
Native process:
Using the running image of child process 1097968.
^^^^^^^^^^^^^^^
...
(gdb) info program
Using the running image of child process 1097968.
^^^^^^^^^^^^^^^
Program stopped at 0x555555555278.
...
... which I think makes a lot more sense in this context. The "info
program" manual entry even says:
"Display information about the status of your program: whether it is
running or not, what process it is, and why it stopped."
^^^^^^^^^^^^^
This change affects ptrace targets, procfs targets, and Windows.
H.J. Lu [Sat, 3 Dec 2022 02:43:20 +0000 (18:43 -0800)]
x86: Allow 16-bit register source for LAR and LSL
Since LAR and LSL only access 16 bits of the source operand, regardless
of operand size, allow 16-bit register source for LAR and LSL, and always
disassemble LAR and LSL with 16-bit source operand.
Simon Marchi [Fri, 25 Nov 2022 21:27:15 +0000 (16:27 -0500)]
gdb/linux-nat: add pid parameter to linux_proc_xfer_memory_partial
Add a pid parameter to linux_proc_xfer_memory_partial, making the
inferior_ptid reference bubble up close to the target_ops::xfer_partial
boundary. No behavior change expected.
Simon Marchi [Mon, 28 Nov 2022 16:43:13 +0000 (11:43 -0500)]
gdb: merge solib-frv aix-solib debug options into "set/show debug solib"
solib implementations are typically used one at a time. So it will be
rare that you will want to enable debug for one solib kind, and
absolutely want to keep the others disabled. To make things simpler,
instead of adding separate variables / macros / commands for each solib
implementation, merge the existing ones (frv and aix) into a unified
"set/show debug solib", with the solib_debug_printf macro.
Jan Beulich [Fri, 2 Dec 2022 08:54:09 +0000 (09:54 +0100)]
x86: drop most OPERAND_TYPE_* (and rework the rest)
With the general use of C99 there's no need anymore to have i386-gen
produce these. For more frequently used ones introduce local #define-s,
while others are simply spelled out directly. While doing this move
some static constants into more narrow scopes.
Note that as a "side effect" this corrects type_names[]'es imm8s entry.
Jan Beulich [Fri, 2 Dec 2022 08:53:33 +0000 (09:53 +0100)]
x86: simplify and slightly correct XCHG vs NOP checking
For one, because of CheckRegSize, there's no need to check the size of
both (register) operands. And then in process_suffix() check opcode
space rather than the (potentially ambiguous) extension opcode.
Jan Beulich [Fri, 2 Dec 2022 08:53:07 +0000 (09:53 +0100)]
x86: also use D for XCHG and TEST
Leverage the C (commutative) attribute to also reduce the number of XCHG
and TEST templates we have. This way the reg <-> r/m (and reg <-> reg for
XCHG) forms can also be folded into a single template each, utilizing D.
Tom de Vries [Fri, 2 Dec 2022 07:56:42 +0000 (08:56 +0100)]
[gdb/testsuite] Prevent timeout in gdb.ada/float-bits.exp
Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le") started using command "maint print architecture", which
produces ~275 lines.
Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
timeouts on slower test setups.
Note that this doesn't fix a timeout in the test-case on aarch64 due to:
...
gdbarch_dump: read_core_file_mappings = <0x817438>
(gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
...
Carl Love [Thu, 1 Dec 2022 19:39:45 +0000 (14:39 -0500)]
PowerPC, fix gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp
The tests set a break point with the command break *func. This sets a
breakpoint on the first instruction of the function. PowerPC uses
Global Entry Points (GEP) and Local Entry Points (LEP). The first
instruction in the function is the GEP. The GEP sets up register
r2 before reaching the LEP. When the function is called with func() the
function is entered via the LEP and the test fails because GDB does not
see the breakpoint on the GEP. However, if the function is called via a
function pointer, execution begins at the GEP as the test expects.
Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and
next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new
source file was created for tests finish-reverse-bkpt.exp and
next-reverse-bkpt-over-sr.exp. The new files use the new function
pointer method to call the functions so the tests will work correctly on
both PowerPC with a GEP and LEP as well as on other systems. The GEP is
the same as the LEP on non PowerPC systems.
The expect files were changed to use the new source files and to set the
initial break point for the rest of the test on the function pointer call
for the function.
This patch fixes two PowerPC test failures in each of the tests
gdb.reverse/finish-reverse-bkpt.exp and
gdb.reverse/next-reverse-bkpt-over-sr.exp.
Patch tested on PowerPC and Intel X86-64 with no regressions.
Tom Tromey [Wed, 30 Nov 2022 20:50:27 +0000 (13:50 -0700)]
Remove call to registers_changed from windows-nat.c
I noticed that windows_nat_target::interrupt calls registers_changed.
However, I don't think there's any reason to do this, because this
will happen automatically when the inferior stop is processed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 30 Nov 2022 15:51:09 +0000 (08:51 -0700)]
Remove the_windows_nat_target global
I belatedly realized that the "the_windows_nat_target" global isn't
really necessary. It's only used in one place, where 'this' would be
simpler and clearer. This patch removes the global entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Thu, 3 Nov 2022 19:49:17 +0000 (13:49 -0600)]
Add name canonicalization for C
PR symtab/29105 shows a number of situations where symbol lookup can
result in the expansion of too many CUs.
What happens is that lookup_signed_typename will try to look up a type
like "signed int". In cooked_index_functions::expand_symtabs_matching,
when looping over languages, the C++ case will canonicalize this type
name to be "int" instead. Then this method will proceed to expand
every CU that has an entry for "int" -- i.e., nearly all of them. A
crucial component of this is that the caller, objfile::lookup_symbol,
does not do this canonicalization, so when it tries to find the symbol
for "signed int", it fails -- causing the loop to continue.
This patch fixes the problem by introducing name canonicalization for
C. The idea here is that, by making C and C++ agree on the canonical
name when a symbol name can have multiple spellings, we avoid the bad
behavior in objfile::lookup_symbol (and any other such code -- I don't
know if there is any).
Unlike C++, C only has a few situations where canonicalization is
needed. And, in particular, due to the lack of overloading (thus
avoiding any issues in linespec) and due to the way c-exp.y works, I
think that no canonicalization is needed during symbol lookup -- only
during symtab construction. This explains why lookup_name_info is not
touched.
The stabs reader is modified on a "best effort" basis.
The DWARF reader needed one small tweak in dwarf2_name to avoid a
regression in dw2-unusual-field-names.exp. I think this is adequately
explained by the comment, but basically this is a scenario that should
not occur in real code, only the gdb test suite.
lookup_signed_typename is simplified. It used to search for two
different type names, but now gdb can search just for the canonical
form.
gdb.dwarf2/enum-type.exp needed a small tweak, because the
canonicalizer turns "unsigned integer" into "unsigned int integer".
It seems better here to use the correct C type name.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 Tested-by: Simon Marchi <simark@simark.ca> Reviewed-by: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Fri, 4 Nov 2022 20:08:13 +0000 (14:08 -0600)]
Remove language check from dwarf2_compute_name
dwarf2_compute_name has a redundant check of the CU's language -- this
is also checked in dwarf2_canonicalize_name. Removing this slightly
simplifies a future patch.
Simon Marchi [Thu, 1 Dec 2022 16:44:41 +0000 (11:44 -0500)]
gdb/dwarf: add some QUIT macros
While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way
out of GDB expanding many symtabs. GDB was busy in a loop in
cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I
also happened to see a spot in
cooked_index_functions::expand_matching_symbols where a QUIT would be
useful too, since we iterate over a potentially big number of index
entries and expand CUs in the loop. Add one there too.
Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3 Approved-By: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Tue, 29 Nov 2022 16:28:58 +0000 (11:28 -0500)]
gdb: remove prune_threads in thread_db_target::update_thread_list
Pedro mentioned that this prune_threads call in
thread_db_target::update_thread_list was not needed, and it was probably
an oversight to leave it there in the work following commit e8032dde10b
("Push pruning old threads down to the target"). That commit changed
the "find new threads" target operation to "update thread list", making
the target responsible of adding new threads and removing exited
threads, rather than just adding new threads. Commit e8032dde10b moved
the prune_threads calls previously done in common code into each
target's update_thread_list method, in order to keep the existing
behavior, which is why this prune_threads call ended up there.
In the mean time, the linux-nat target was taught to update_thread_list,
and thread_db_target::update_thread_list defers to that for any live
inferior, so the prune_threads call is not needed there. Otherwise, the
thread_db_target::update_thread_list implementation based on
td_ta_thr_iter_p only knows how to add new threads, not how to delete
exited threads, but that is only used for non-live inferiors, where
threads can't exit anyway. So the prune_threads call is not needed for
that case either.
Change-Id: I127fd4f84c25086f97853dadf34c5cec6816840d Approved-By: Pedro Alves <pedro@palves.net>
Tom Tromey [Wed, 30 Nov 2022 18:27:10 +0000 (11:27 -0700)]
Avoid timeouts in gdb.compile
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Tom Tromey [Wed, 30 Nov 2022 17:09:20 +0000 (10:09 -0700)]
Remove obsolete check from skip_compile_feature_tests
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
Tom Tromey [Wed, 30 Nov 2022 16:32:04 +0000 (09:32 -0700)]
Remove one copy of skip_compile_feature_tests
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
Clément Chigot [Thu, 1 Dec 2022 08:57:09 +0000 (09:57 +0100)]
binutils: improve holes detection in .debug_loclists.
The previous warnings about holes in .debug_loclists sections don't
take into account the headers of each CU and could include the locviews
if they precede the loclist.
The following warning can be triggered between two CU.
... <previous CU views> ... 0000001d <End of list>
Nick Clifton [Thu, 1 Dec 2022 13:09:26 +0000 (13:09 +0000)]
Fix verilog output when the width is > 1.
PR 25202
bfd * bfd.c (VerilogDataEndianness): New variable.
(verilog_write_record): Use VerilogDataEndianness, if set, to
choose the endianness of the output.
(verilog_write_section): Adjust the address by the data width.
binutils* objcopy.c (copy_object): Set VerilogDataEndianness to the
endianness of the input file.
(copy_main): Verifiy the value set by the --verilog-data-width
option.
* testsuite/binutils-all/objcopy.exp: Add tests of the new behaviour.
* testsuite/binutils-all/verilog-I4.hex: New file.
Jan Beulich [Thu, 1 Dec 2022 09:00:26 +0000 (10:00 +0100)]
x86: rework of match_template()'s suffix checking
(Ab)using i386_opcode_modifier for this has been overkill, as the logic
doesn't really require the full structure. With the removal of
LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf there's no good reason at all
anymore to pull out such a loop invariant: We're dealing a check of a
bit in the loop for a simple comparison. Do the original compares inside
the loop, thus also making it easier to understand what is actually
being checked.
Jan Beulich [Thu, 1 Dec 2022 08:59:39 +0000 (09:59 +0100)]
x86/Intel: drop LONG_DOUBLE_MNEM_SUFFIX
With the removal of its use for FPU insns the suffix is now finally
properly misnamed. Drop its use altogether, replacing it by a separate
boolean instead.
Jan Beulich [Thu, 1 Dec 2022 08:59:11 +0000 (09:59 +0100)]
x86/Intel: restrict use of LONG_DOUBLE_MNEM_SUFFIX
As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)
Tom de Vries [Thu, 1 Dec 2022 06:25:04 +0000 (07:25 +0100)]
[gdb/testsuite] Wait longer for core generation
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux. Approved-By: Tom Tromey <tom@tromey.com>
The problem is that we're using a hex string for the 128-bit IEEE quad long
double format, but the actual long double float format is:
...
gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
...
Fix this by using the hex string obtained by compiling test.c:
...
long double a = 5.0e+25L;
...
like so:
...
$ gcc -mlittle test.c -c -g
...
and running gdb:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0xc1e1c000000000004544adf4b7320335
...
and likewise for -mbig:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0x4544adf4b7320335c1e1c00000000000
...
Tested on powerpc64le-linux.
I excercised the case of floatformat_ibm_long_double_big by
using "set endian big" in the test-case.
Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
Improve printing of float formats") is required.
PR testsuite/29816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Wed, 30 Nov 2022 18:29:52 +0000 (19:29 +0100)]
[gdb/testsuite] Fix DUPLICATEs in s390-multiarch.exp
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Tom de Vries [Wed, 30 Nov 2022 17:49:16 +0000 (18:49 +0100)]
[gdb/testsuite] Enable gdb.arch/s390-disassembler-options.exp for --enable-targets=all
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
show disassembler-options esa
...
First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.
Fix the DUPLICATE by using with_test_prefix.
Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
Michael Matz [Wed, 16 Nov 2022 15:28:01 +0000 (16:28 +0100)]
section-select: Fix exclude-file-3
this testcase wasn't correctly testing everything, it passed, even
though sections from an excluded file were included. Fixing this
reveals a problem in the new section selector. This fixes that as
well.
Michael Matz [Tue, 22 Nov 2022 14:24:43 +0000 (15:24 +0100)]
section-select: Remove unused code
walk_wild_file, hence walk_wild_section and walk_wild_section_handler
aren't called with the prefix tree. Hence initialization of the latter
and all potential special cases for it aren't used anymore. That also
removes the need to handler_data[] and some associated helper functions.
So, remove all of that.
Michael Matz [Wed, 14 Sep 2022 15:10:27 +0000 (17:10 +0200)]
section-select: Implement a prefix-tree
Now that we have a list of potentially matching sections per wild
statement we can actually pre-fill that one by going once over all input
sections and match their names against a prefix-tree that points to the
potentially matching wild statements.
So instead of looking at all sections names for each glob for each wild
statement we now look at the sections only once and then only check
against those globs that have a possibility of a match at all (usually
only one or two).
This pushes the whole section selection off the profiles.
Michael Matz [Thu, 27 Oct 2022 12:50:40 +0000 (14:50 +0200)]
section-select: Completely rebuild matches
The check_relocs callback (and others) might have created new
section behind our back and some of them (e.g. on powerpc the
"linker stubs" .got) need to come in front of all others, despite
being created late (a symptom would be "TOC opt*" failing on powerpc).
This resets all section matches before updating for newly created
sections (i.e. completely rebuilds the matches).
Michael Matz [Thu, 28 Jul 2022 12:55:05 +0000 (14:55 +0200)]
section-select: Lazily resolve section matches
and remember the results. Before this the order of section matching
is basically:
foreach script-wild-stmt S
foreach pattern P of S
foreach inputfile I
foreach section S of I
match S against P
if match: do action for S
And this process is done three or four times: for each top-level call to
walk_wild() or wild(), that is: check_input_sections, lang_gc_sections,
lang_find_relro_sections and of course map_input_to_output_sections.
So we iterate over all sections of all files many many times (for each
glob). Reality is a bit more complicated (some special glob types don't
need the full iteration over all sections, only over all files), but
that's the gist of it.
For future work this shuffles the whole ordering a bit by lazily doing
the matching process and memoizing results, trading a little memory for
a 75% speedup of the overall section selection process.
This lazy resolution introduces a problem with sections added late
that's corrected in the next patch.
Tom Tromey [Wed, 16 Nov 2022 20:58:06 +0000 (13:58 -0700)]
Bounds check access to Ada task state names
While looking into Ada tasking a little, I noticed that no bounds
checking is done on accesses to the Ada task state names arrays. This
isn't a problem currently, but if the runtime ever added numbers -- or
if there was some kind of runtime corruption -- it could cause a gdb
crash.
This patch adds range checking. It also adds a missing _() call when
printing from the 'task_states' array.
Tom Tromey [Mon, 28 Nov 2022 21:01:35 +0000 (14:01 -0700)]
Rename fields of cli_interp_base::saved_output_files
This renames the fields of cli_interp_base::saved_output_files, as
requested by Simon. I tried to choose names that more obviously
reflect what the field is used for. I also added a couple of
comments.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Wed, 30 Nov 2022 10:37:11 +0000 (11:37 +0100)]
[gdb] Improve printing of float formats
Currently, on x86_64, a little endian target, I get:
...
$ gdb -q -batch -ex "maint print architecture" | grep " = floatformat"
gdbarch_dump: bfloat16_format = floatformat_bfloat16_big
gdbarch_dump: double_format = floatformat_ieee_double_big
gdbarch_dump: float_format = floatformat_ieee_single_big
gdbarch_dump: half_format = floatformat_ieee_half_big
gdbarch_dump: long_double_format = floatformat_i387_ext
...
which suggests big endian.
This is due to this bit of code in pformat:
...
/* Just print out one of them - this is only for diagnostics. */
return format[0]->name;
...
Fix this by using gdbarch_byte_order to pick the appropriate index, such that
we have the more accurate:
...
gdbarch_dump: bfloat16_format = floatformat_bfloat16_little
gdbarch_dump: half_format = floatformat_ieee_half_little
gdbarch_dump: float_format = floatformat_ieee_single_little
gdbarch_dump: double_format = floatformat_ieee_double_little
gdbarch_dump: long_double_format = floatformat_i387_ext
...
Jan Beulich [Wed, 30 Nov 2022 08:10:17 +0000 (09:10 +0100)]
x86/Intel: adjustment to restricted suffix derivation
In "x86/Intel: restrict suffix derivation" I think I screwed up
slightly, bringing a piece of code out of sync with its comment, and
resulting in a suffix potentially being derived when one isn't needed.
Jan Beulich [Wed, 30 Nov 2022 08:06:59 +0000 (09:06 +0100)]
x86: clean up after removal of support for gcc <= 2.8.1
At the very least a comment in process_operands() is stale. Beyond that
there are effectively two options:
1) It is possible that FADDP and FMULP were mistakenly not marked as
being in need of dealing with the compiler anomaly, and hence the
respective templates weren't removed at the time when they should
have been.
2) It is also possible that there are indeed uses known beyond compiler
generated output for these two commutative opcodes, and hence the
templates need to stay.
To be on the safe side assume 2: Update the comment and fold the
templates into their "normal" ones (utilizing D), adjusting consuming
code accordingly.
For FMULP also add a comment paralleling a similar one FADDP has.
Jan Beulich [Wed, 30 Nov 2022 08:06:33 +0000 (09:06 +0100)]
x86: drop FloatR
There are just 4 templates using it, which can be easily identified by
other means, as D is set only on a very limited number of FPU templates.
Also move the respective conditional out of the code path taken by all
"reverse match" insns (it probably should have been this way already
before, to avoid the one conditional in the common case).
With this the templates which had FloatR dropped no longer differ from
their AT&T syntax + mnemonic counterparts - the only difference is now
which of the two would be recognized. For this, however, we don't need
two templates - we can simply arrange the condition for setting
Opcode_FloatR accordingly.
Jan Beulich [Wed, 30 Nov 2022 08:05:57 +0000 (09:05 +0100)]
x86: extend FPU test coverage for AT&T / Intel mnemonic differences
Before touching the templates, let's ensure we actually cover things:
For one FSUB{,R} and FDIV{,R} would better be tested with operands in
both possible orders. And then -mmnemonic=intel wasn't tested at all.
Joel Brobecker [Sun, 27 Nov 2022 12:43:42 +0000 (16:43 +0400)]
src-release.sh: Fix gdb source tarball build failure due to libsframe
This script was recently changed as follow:
| commit e619dddb3a45780ae66d762756882a3b896b617d
| Date: Tue Nov 15 15:07:13 2022 -0800
| Subject: src-release.sh: Add libsframe
|
| Add libsframe to the list of top level directories that will be included
| in a release.
Since then, the gdb source tarball has been failing with the error
below during the "make configure-host configure-target" phase:
| make[3]: *** No rule to make target '../libsframe/libsframe.la',
| needed by 'libbfd.la'. Stop.
| make[3]: Leaving directory '/tmp/gdb-public/bfd'
This patch fixes the issue by adding libsframe to the list of
GDB_SUPPORT_DIRS, similar to what was done for BINUTILS.
Tom de Vries [Tue, 29 Nov 2022 21:47:31 +0000 (22:47 +0100)]
[gdb/testsuite] Fix gdb.base/vla-optimized-out.exp for ppc64le
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla
p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \
printed size of optimized out vla
...
The problem happens as follows.
In order to find the size of the optimized out vla, gdb needs to evaluate:
...
<155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \
(DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1;
DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
DW_OP_minus)
...
When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site
matching the pc, but doesn't find it:
...
$ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \
-ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)"
Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34.
Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34
34 }
DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main
$1 = <optimized out>
....
The call site lookup fails because the call site label .LVL4:
...
bl f1 # 11 *call_value_nonlocal_aixdi [length = 8]
nop
.LVL4:
...
is not placed directly after the bl insn. This is gcc PR target/107909.
However, after manually fixing the .s file we have instead:
...
Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main
$1 = <optimized out>
...
due to the fact that the call site has no call site parameters.
The call site does have a reference to the corresponding function f1, with
parameter i, for which we find location list entries:
...
0037 1000067c10000680 (DW_OP_reg3 (r3))
004a 1000068010000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3));
DW_OP_stack_value)
...
and we could use the fact that the current pc is in the 1000067c-10000680
range, and that that the range starts at the start of the function, to deduce
that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3).
But that's a non-trivial enhancement, filed as enhancement PR symtab/29836.
Fix this by allowing <optimized out> for target powerpc and the gcc compiler.
Reviewed-By: Carl Love <cel@us.ibm.com> Tested-By: Carl Love <cel@us.ibm.com>
PR testsuite/29813
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48 Approved-By: Tom de Vries <tdevries@suse.de>
... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception. This is a bit sneaky, because ERRORs are not
reported in the test summary. In certain circumstances, it can be easy
to miss.
Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
this is only if it manages to send the command, and it's that command
that crashes GDB. Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command. GDB was crashed by the previous "file" command, sent by
gdb_unload. Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).
In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails. This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED. It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.
Before, it looks like:
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
And after:
Couldn't send python print(objfile.filename) to GDB.
UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba Approved-By: Tom de Vries <tdevries@suse.de>
Max Filippov [Wed, 3 May 2017 20:13:52 +0000 (13:13 -0700)]
xtensa: allow dynamic configuration
Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v<x> function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that tries to load
configuration and return an address of an exported object from it.
Define functions xtensa_get_config_v{1,2} that use xtensa_load_config
to get structures xtensa_config_v{1,2}, either dynamically configured
or the default.
bfd/
* Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Append
xtensa-dynconfig.c.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac (xtensa_elf32_be_vec, xtensa_elf32_le_vec): Add
xtensa-dynconfig.lo to the tb.
* elf32-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XSHAL_ABI, XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove
definitions.
* xtensa-dynconfig.c: New file.
* xtensa-isa.c (xtensa-dynconfig.h): New #include.
(xtensa_get_modules): New function.
(xtensa_isa_init): Call xtensa_get_modules instead of taking
address of global xtensa_modules.
gas/
* config/tc-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0, XTENSA_MARCH_EARLIEST):
Remove definitions.
* config/tc-xtensa.h (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
* config/xtensa-relax.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XCHAL_HAVE_WIDE_BRANCHES): Remove definition.
Andrew Burgess [Mon, 14 Nov 2022 14:45:05 +0000 (14:45 +0000)]
gdb/testsuite: remove use of then keyword from library files
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
Andrew Burgess [Mon, 14 Nov 2022 14:31:52 +0000 (14:31 +0000)]
gdb/testsuite: remove use of then keyword from gdb.*/*.exp scripts
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the remaining
gdb.*/*.exp scripts. Previous commits have done the bulk of this
removal, this commit just handles the remaining directories that each
contain a low number of instances.
There should be no changes in what is tested after this commit.
Andrew Burgess [Mon, 14 Nov 2022 14:28:22 +0000 (14:28 +0000)]
gdb/testsuite: remove use of then keyword from gdb.multi/*.exp
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.multi/
test script directory.
There should be no changes in what is tested after this commit.
projects / thirdparty / binutils-gdb.git / log
