forked from Imagelibrary/binutils-gdb
244ac24b51ba1375794eed93b58d5813e7c044ca
1174 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Tom Tromey
|
7904e9613e |
Move gdb_argv to gdbsupport
This moves the gdb_argv class to a new header in gdbsupport. |
||
|
Simon Marchi
|
8bf10e2e77 |
gdb/infrun: rename variable and move to more specific scope
Move the "started" variable to the scope it's needed, and rename it to "step_over_started". Change-Id: I56f3384dbd328f55198063bb855edda10f1492a3 |
||
|
Joel Brobecker
|
4a94e36819 |
Automatic Copyright Year update after running gdb/copyright.py
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script. |
||
|
Simon Marchi
|
577d2167bb |
gdb: move clearing of tp->pending_follow to follow_fork_inferior
A following patch will change targets so that when they detach an inferior, they also detach any pending fork children this inferior may have. While doing this, I hit a case where we couldn't differentiate two cases, where in one we should detach the fork detach but not in the other. Suppose we continue past a fork with "follow-fork-mode == child" && "detach-on-fork on". follow_fork_inferior calls target_detach to detach the parent. In that case the target should not detach the fork child, as we'll continue debugging the child. As of now, the tp->pending_follow field of the thread who called fork still contains the details about the fork. Then, suppose we run to a fork catchpoint and the user types "detach". In that case, the target should detach the fork child in addition to the parent. In that case as well, the tp->pending_follow field contains the details about the fork. To allow targets to differentiate the two cases, clear tp->pending_follow a bit earlier, when following a fork. Targets will then see that tp->pending_follow contains TARGET_WAITKIND_SPURIOUS, and won't detach the fork child. As of this patch, no behavior changes are expected. Change-Id: I537741859ed712cb531baaefc78bb934e2a28153 |
||
|
Simon Marchi
|
c272a98cbf |
gdb: pass more const target_waitstatus by reference
While working on target_waitstatus changes, I noticed a few places where const target_waitstatus objects could be passed by reference instead of by pointers. And in some cases, places where a target_waitstatus could be passed as const, but was not. Convert them as much as possible. Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a |
||
|
Simon Marchi
|
7dca2ea7ff |
gdb: rename target_waitstatus_to_string to target_waitstatus::to_string
Make target_waitstatus_to_string a "to_string" method of target_waitstatus, a bit like we have ptid_t::to_string already. This will save a bit of typing. Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905 |
||
|
Simon Marchi
|
557b4d7650 |
gdbsupport: make gdb_assert_not_reached accept a format string
Change gdb_assert_not_reached to accept a format string plus corresponding arguments. This allows giving more precise messages. Because the format string passed by the caller is prepended with a "%s:" to add the function name, the callers can no longer pass a translated string (`_(...)`). Make the gdb_assert_not_reached include the _(), just like the gdb_assert_fail macro just above. Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7 |
||
|
Tom de Vries
|
636ae5bb4b |
[gdb] Don't use gdb_stdlog for inferior-events
The test-case gdb.base/foll-vfork.exp contains:
...
if [gdb_debug_enabled] {
untested "debug is enabled"
return 0
}
...
To understand what it does, I disabled this bit and ran with GDB_DEBUG=infrun,
like so:
...
$ cd $build/gdb/testsuite
$ make check GDB_DEBUG=infrun RUNTESTFLAGS=gdb.base/foll-vfork.exp
...
and ran into:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
vfork parent follow, through step: set follow-fork parent
next^M
33 if (pid == 0) {^M
(gdb) FAIL: gdb.base/foll-vfork.exp: exec: \
vfork parent follow, through step: step
...
The problem is that the test-case expects:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
vfork parent follow, through step: set follow-fork parent
next^M
[Detaching after vfork from child process 28169]^M
33 if (pid == 0) {^M
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
vfork parent follow, through step: step
...
but the "Detaching" line has been redirected to
$outputs/gdb.base/foll-vfork/gdb.debug.
I looked at the documentation of "set logging debugredirect [on|off]":
...
By default, GDB debug output will go to both the terminal and the logfile.
Set debugredirect if you want debug output to go only to the log file.
...
and my interpretation of it was that "debug output" did not match the
"messages" description of inferior-events:
...
The set print inferior-events command allows you to enable or disable printing
of messages when GDB notices that new inferiors have started or that inferiors
have exited or have been detached.
...
Fix the discrepancy by not using gdb_stdlog for inferior-events.
Update the gdb.base/foll-vfork.exp test-case to not require
gdb_debug_enabled == 0.
Tested on x86_64-linux.
Tested test-case gdb.base/foll-vfork.exp with and without GDB_DEBUG=infrun.
|
||
|
Simon Marchi
|
4d772ea24d |
gdb: fix "set scheduler-locking" thread exit hang
GDB hangs when doing this:
- launch inferior with multiple threads
- multiple threads hit some breakpoint(s)
- one breakpoint hit is presented as a stop, the rest are saved as
pending wait statuses
- "set scheduler-locking on"
- resume the currently selected thread (because of scheduler-locking,
it's the only one resumed), let it execute until exit
- GDB hangs, not showing the prompt, impossible to interrupt with ^C
When the resumed thread exits, we expect the target to return a
TARGET_WAITKIND_NO_RESUMED event, and that's what we see:
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] random_pending_event_thread: None found.
[Thread 0x7ffff7d9c700 (LWP 309357) exited]
[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
[infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
[infrun] fetch_inferior_event: exit
The problem is in handle_no_resumed: we check if some other thread is
actually resumed, to see if we should ignore that event (see comments in
that function for more info). If this condition is true:
(thread->executing () || thread->has_pending_waitstatus ())
... then we ignore the event. The problem is that there are some non-resumed
threads with a pending event, which makes us ignore the event. But these
threads are not resumed, so we end up waiting while nothing executes, hence
waiting for ever.
My first fix was to change the condition to:
(thread->executing ()
|| (thread->resumed () && thread->has_pending_waitstatus ()))
... but then it occured to me that we could simply check for:
(thread->resumed ())
Since "executing" implies "resumed", checking simply for "resumed"
covers threads that are resumed and executing, as well as threads that
are resumed with a pending status, which is what we want.
Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780
|
||
|
Simon Marchi
|
313f3b21cb |
gdb: remove bpstat typedef, rename bpstats to bpstat
I don't find that the bpstat typedef, which hides a pointer, is particularly useful. In fact, it confused me many times, and I just see it as something to remember that adds cognitive load. Also, with C++, we might want to be able to pass bpstats objects by const-reference, not necessarily by pointer. So, remove the bpstat typedef and rename struct bpstats to bpstat (since it represents one bpstat, it makes sense that it is singular). Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849 |
||
|
Simon Marchi
|
0fab795564 |
gdb: use ptid_t::to_string in infrun debug messages
In debug messages, I think it would be more helpful to print ptid using
the simple "pid.lwp.tid" notation in infrun debug messages. I am
currently debugging some fork issues, and find the pid_to_str output not
so useful, as it doesn't tell which process a thread belongs to.
It currently shows up like this:
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7d95740 (LWP 892942)] at 0x55555555521f
With the patch, it shows up like this:
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [894072.894077.0] at 0x5555555551d9
Change-Id: I130796d7dfb0d8e763b8358d8a6002701d80c4ea
|
||
|
Simon Marchi
|
50888e42dc |
gdb: change functions returning value contents to use gdb::array_view
The bug fixed by this [1] patch was caused by an out-of-bounds access to a value's content. The code gets the value's content (just a pointer) and then indexes it with a non-sensical index. This made me think of changing functions that return value contents to return array_views instead of a plain pointer. This has the advantage that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view are checked, making bugs more apparent / easier to find. This patch changes the return types of these functions, and updates callers to call .data() on the result, meaning it's not changing anything in practice. Additional work will be needed (which can be done little by little) to make callers propagate the use of array_view and reap the benefits. [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3 |
||
|
Simon Marchi
|
183be22290 |
gdb, gdbserver: make target_waitstatus safe
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
|
||
|
Tom Tromey
|
9279eb5c2c |
Fix Windows crash from stop_pc change
The "make thread_suspend_state::stop_pc optional" patch caused a regression on Windows when using shared libraries. I tracked this down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED case of handle_inferior_event. This patch fixes the bug by ensuring that the stop PC is set at this point. |
||
|
Simon Marchi
|
da474da158 |
gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"
We found that when handling forks, two inferiors can unexpectedly share
their program space and address space. To reproduce:
1. Using a test program that forks...
2. "set follow-fork-mode child"
3. "set detach-on-fork on" (the default)
4. run to a breakpoint somewhere after the fork
Step 4 should have created a new inferior:
(gdb) info inferiors
Num Description Connection Executable
1 <null> /home/smarchi/build/wt/amd/gdb/fork
* 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork
By inspecting the state of GDB, we can see that the two inferiors now
share one program space and one address space:
Inferior 1:
(top-gdb) p inferior_list.m_front.num
$2 = 1
(top-gdb) p inferior_list.m_front.aspace
$3 = (struct address_space *) 0x5595e2520400
(top-gdb) p inferior_list.m_front.pspace
$4 = (struct program_space *) 0x5595e2520440
Inferior 2:
(top-gdb) p inferior_list.m_front.next.num
$5 = 2
(top-gdb) p inferior_list.m_front.next.aspace
$6 = (struct address_space *) 0x5595e2520400
(top-gdb) p inferior_list.m_front.next.pspace
$7 = (struct program_space *) 0x5595e2520440
You can then run inferior 1 again and the two inferiors will still
erroneously share their spaces, but already at this point this is wrong.
The cause of the bad {a,p}space sharing is in follow_fork_inferior.
When following the child and detaching from the parent, we just re-use
the parent's spaces, rather than cloning them. When we switch back to
inferior 1 and run again, we find ourselves with two unrelated inferiors
sharing spaces.
Fix that by creating new spaces for the parent after having moved them
to the child. My initial implementation created new spaces for the
child instead. Doing this breaks doing "next" over fork(). When "next"
start, we record the symtab of the starting location. When the program
stops, we compare that symtab with the symtab the program has stopped
at. If the symtab or the line number has changed, we conclude the
"next" is done. If we create a new program space for the child and copy
the parent's program space to it with clone_program_space, it creates
new symtabs for the child as well. When the child stop, but still on
the fork() line, GDB thinks the "next" is done because the symtab
pointers no longer match. In reality they are two symtab instances that
represent the same file. But moving the spaces to the child and
creating new spaces for the parent, we avoid this problem.
Note that the problem described above happens today with "detach-on-fork
off" and "follow-fork-mode child", because we create new spaces for the
child. This will have to be addressed later.
Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
expected to have a location in each inferiors. Without the fix, when
the two inferiors erroneously share a program space, GDB reports a
single location.
Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e
|
||
|
Simon Marchi
|
25558938d0 |
gdb: change thread_info::name to unique_xmalloc_ptr, add helper function
This started out as changing thread_info::name to a unique_xmalloc_ptr. That showed that almost all users of that field had the same logic to get a thread's name: use thread_info::name if non-nullptr, else ask the target. Factor out this logic in a new thread_name free function. Make the field private (rename to m_name) and add some accessors. Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc |
||
|
Tom Tromey
|
96bbe3ef96 |
Change ptid_t::tid to ULONGEST
The ptid_t 'tid' member is normally used as an address in gdb -- both bsd-uthread and ravenscar-thread use it this way. However, because the type is 'long', this can cause problems with sign extension. This patch changes the type to ULONGEST to ensure that sign extension does not occur. |
||
|
Andrew Burgess
|
351031f22a |
gdb: make thread_suspend_state::stop_pc optional
Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and when we want to indicate that there is no stop_pc available we set this field back to a special value. There are actually two special values used, in post_create_inferior the stop_pc is set to 0. This is a little unfortunate, there are plenty of embedded targets where 0 is a valid pc value. The more common special value for stop_pc though, is set in thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used. This commit changes things so that the stop_pc is instead a gdb::optional. We can now explicitly reset the field to an uninitialised state, we also have asserts that we don't read the stop_pc when its in an uninitialised state (both in gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG defined, and in thread_info::stop_pc). One situation where a thread will not have a stop_pc value is when the thread is stopped as a consequence of GDB being in all stop mode, and some other thread stopped at an interesting event. When GDB brings all the other threads to a stop those other threads will not have a stop_pc set (thus avoiding an unnecessary read of the pc register). Previously, when GDB passed through handle_one (in infrun.c) the threads executing flag was set to false and the stop_pc field was left unchanged, i.e. it would (previous) have been left as ~0. Now, handle_one leaves the stop_pc with no value. This caused a problem when we later try to set these threads running again, in proceed() we compare the current pc with the cached stop_pc. If the thread was stopped via handle_one then the stop_pc would have been left as ~0, and the compare (in proceed) would (likely) fail. Now however, this compare tries to read the stop_pc when it has no value and this would trigger an assert. To resolve this I've added thread_info::stop_pc_p() which returns true if the thread has a cached stop_pc. We should only ever call thread_info::stop_pc() if we know that there is a cached stop_pc, however, this doesn't mean that every call to thread_info::stop_pc() needs to be guarded with a call to thread_info::stop_pc_p(), in most cases we know that the thread we are looking at stopped due to some interesting event in that thread, and so, we know that the stop_pc is valid. After running the testsuite I've seen no other situations where stop_pc is read uninitialised. There should be no user visible changes after this commit. |
||
|
Andrew Burgess
|
611841bb1a |
gdb: make thread_info::executing private
Rename thread_info::executing to thread_info::m_executing, and make it private. Add a new get/set member functions, and convert GDB to make use of these. The only real change of interest in this patch is in thread.c where I have deleted the helper function set_executing_thread, and now just use the new set function thread_info::set_executing. However, the old helper function set_executing_thread included some code to reset the thread's stop_pc, so I moved this code into the new function thread_info::set_executing. However, I don't believe there is anywhere that this results in a change of behaviour, previously the executing flag was always set true through a call to set_executing_thread anyway. |
||
|
Simon Marchi
|
9fe3819e83 |
gdb: remove breakpoint_find_if
Remove breakpoint_find_if, replace its sole usage with using all_breakpoints directly instead. At the same time, change return types to use bool. Change-Id: I9ec392236b4804b362d16ab563330b9c07311106 |
||
|
Simon Marchi
|
69eadcc9ea |
gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit
I spotted what I think is a buglet in proceed_after_vfork_done. After a
vfork child exits or execs, we resume all the threads of the parent. To
do so, we iterate on all threads using iterate_over_threads with the
proceed_after_vfork_done callback. Each thread is resumed if the
following condition is true:
if (thread->ptid.pid () == pid
&& thread->state == THREAD_RUNNING
&& !thread->executing
&& !thread->stop_requested
&& thread->stop_signal () == GDB_SIGNAL_0)
where `pid` is the pid of the vfork parent. This is not multi-target
aware: since it only filters on pid, if there is an inferior with the
same pid in another target, we could end up resuming a thread of that
other inferior. The chances of the stars aligning for this to happen
are tiny, but still.
Fix that by iterating only on the vfork parent's threads, instead of on
all threads. This is more efficient, as we iterate on just the required
threads (inferiors have their own thread list), and we can drop the pid
check. The resulting code is also more straightforward in my opinion,
so it's a win-win.
Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a
|
||
|
Simon Marchi
|
17e971f729 |
gdb: use ptid_t::to_string in print_target_wait_results
The ptid_t::to_string method was introduced recently, to format a ptid_t for debug purposes. It formats the ptid exactly as is done in print_target_wait_results, so make print_target_wait_results use it. Change-Id: I0a81c8040d3e1858fb304cb28366b34d94eefe4d |
||
|
Simon Marchi
|
82d1f134cc |
gdb: follow-fork: push target and add thread in target_follow_fork
In the context of ROCm-gdb [1], the ROCm target sits on top of the linux-nat target. when a process forks, it needs to carry over some data from the forking inferior to the fork child inferior. Ideally, the ROCm target would implement the follow_fork target_ops method, but there are some small problems. This patch fixes these, which helps the ROCm target, but also makes things more consistent and a bit nicer in general, I believe. The main problem is: when follow-fork-mode is "parent", target_follow_fork is called with the parent as the current inferior. When it's "child", target_follow_fork is called with the child as the current inferior. This means that target_follow_fork is sometimes called on the parent's target stack and sometimes on the child's target stack. The parent's target stack may contain targets above the process target, such as the ROCm target. So if follow-fork-child is "parent", the ROCm target would get notified of the fork and do whatever is needed. But the child's target stack, at that moment, only contains the exec and process target copied over from the parent. The child's target stack is set up by follow_fork_inferior, before calling target_follow_fork. In that case, the ROCm target wouldn't get notified of the fork. For consistency, I think it would be good to always call target_follow_fork on the parent inferior's target stack. I think it makes sense as a way to indicate "this inferior has called fork, do whatever is needed". The desired outcome of the fork (whether an inferior is created for the child, do we need to detach from the child) can be indicated by passed parameter. I therefore propose these changes: - make follow_fork_inferior always call target_follow_fork with the parent as the current inferior. That lets all targets present on the parent's target stack do some fork-related handling and push themselves on the fork child's target stack if needed. For this purpose, pass the child inferior down to target_follow_fork and follow_fork implementations. This is nullptr if no inferior is created for the child, because we want to detach from it. - as a result, in follow_fork_inferior, detach from the parent inferior (if needed) only after the target_follow_fork call. This is needed because we want to call target_follow_fork before the parent's target stack is torn down. - hand over to the targets in the parent's target stack (including the process target) the responsibility to push themselves, if needed, to the child's target stack. Also hand over the responsibility to the process target, at the same time, to create the child's initial thread (just like we do for follow_exec). - pass the child inferior to exec_on_vfork, so we don't need to swap the current inferior between parent and child. Nothing in exec_on_vfork depends on the current inferior, after this change. Although this could perhaps be replaced with just having the exec target implement follow_fork and push itself in the child's target stack, like the process target does... We would just need to make sure the process target calls beneath()->follow_fork(...). I'm not sure about this one. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Add inferior* parameter. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. (fbsd_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * remote.c (class remote_target) <follow_fork>: Likewise. (remote_target::follow_fork): Likewise, and call process_stratum_target::follow_fork. * process-stratum-target.h (class process_stratum_target) <follow_fork>: New. * process-stratum-target.c (process_stratum_target::follow_fork): New. * target-delegates.c: Re-generate. [1] https://github.com/ROCm-Developer-Tools/ROCgdb Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929 |
||
|
Simon Marchi
|
3a849a3454 |
gdb: pass child_ptid and fork kind to target_ops::follow_fork
This is a small cleanup I think would be nice, that I spotted while doing the following patch. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Add ptid and target_waitkind parameters. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. * fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Likewise. * obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. * remote.c (class remote_target) <follow_fork>: Likewise. * target-debug.h (target_debug_print_target_waitkind): New. * target-delegates.c: Re-generate. Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8 |
||
|
Simon Marchi
|
ff77083572 |
gdb: call post_create_inferior at end of follow_fork_inferior
GDB doesn't handle well the case of an inferior using the JIT interface to register JIT-ed objfiles and forking. If an inferior registers a code object using the JIT interface and then forks, the child process conceptually has the same code object loaded, so GDB should look it up and learn about it (it currently doesn't). To achieve this, I think it would make sense to have the inferior_created observable called when an inferior is created due to a fork in follow_fork_inferior. The inferior_created observable is currently called both after starting a new inferior and after attaching to an inferior, allowing various sub-components to learn about that new executing inferior. We can see handling a fork child just like attaching to it, so any work done when attaching should also be done in the case of a fork child. Instead of just calling the inferior_created observable, this patch makes follow_fork_inferior call the whole post_create_inferior function. This way, the attach and follow-fork code code paths are more alike. Given that post_create_inferior calls solib_create_inferior_hook, follow_fork_inferior doesn't need to do it itself, so those calls to solib_create_inferior_hook are removed. One question you may have: why not just call post_create_inferior at the places where solib_create_inferior_hook is currently called, instead of after target_follow_fork? - there's something fishy for the second solib_create_inferior_hook call site: at this point we have switched the current program space to the child's, but not the current inferior nor the current thread. So solib_create_inferior_hook (and everything under, including check_for_thread_db, for example) is called with inferior 1 as the current inferior and inferior 2's program space as the current program space. I think that's wrong, because at this point we are setting up inferior 2, and all that code relies on the current inferior. We could just add a switch_to_thread call before it to make inferior 2 the current one, but there are other problems (see below). - solib_create_inferior_hook is currently not called on the `follow_child && detach_fork` path. I think we need to call it, because we still get a new inferior in that case (even though we detach the parent). If we only call post_create_inferior where solib_create_inferior_hook used to be called, then the JIT subcomponent doesn't get informed about the new inferior, and that introduces a failure in the new gdb.base/jit-elf-fork.exp test. - if we try to put the post_create_inferior just after the switch_to_thread that was originally at line 662, or just before the call to target_follow_fork, we introduce a subtle failure in gdb.threads/fork-thread-pending.exp. What happens then is that libthread_db gets loaded (somewhere under post_create_inferior) before the linux-nat target learns about the LWPs (which happens in linux_nat_target::follow_fork). As a result, the ALL_LWPS loop in try_thread_db_load_1 doesn't see the child LWP, and the thread-db target doesn't have the chance to fill in thread_info::priv. A bit later, when the test does "info threads", and thread_db_target::pid_to_str is called, the thread-db target doesn't recognize the thread as one of its own, and delegates the request to the target below. Because the pid_to_str output is not the expected one, the test fails. This tells me that we need to call the process target's follow_fork first, to make the process target create the necessary LWP and thread structures. Then, we can call post_create_inferior to let the other components of GDB do their thing. But then you may ask: check_for_thread_db is already called today, somewhere under solib_create_inferior_hook, and that is before target_follow_fork, why don't we see this ordering problem!? Well, because of the first bullet point: when check_for_thread_db / thread_db_load are called, the current inferior is (erroneously) inferior 1, the parent. Because libthread_db is already loaded for the parent, thread_db_load early returns. check_for_thread_db later gets called by linux_nat_target::follow_fork. At this point, the current inferior is the correct one and the child's LWP exists, so all is well. Since we now call post_create_inferior after target_follow_fork, which calls the inferior_created observable, which calls check_for_thread_db, I don't think linux_nat_target needs to explicitly call check_for_thread_db itself, so that is removed. In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp test. It makes an inferior register a JIT code object and then fork. It then verifies that whatever the detach-on-fork and follow-fork-child parameters are, GDB knows about the JIT code object in all the inferiors that survive the fork. It verifies that the inferiors can unload that code object. There isn't currently a way to get visibility into GDB's idea of the JIT code objects for each inferior. For the purpose of this test, add the "maintenance info jit" command. There isn't much we can print about the JIT code objects except their load address. So the output looks a bit bare, but it's good enough for the test. gdb/ChangeLog: * NEWS: Mention "maint info jit" command. * infrun.c (follow_fork_inferior): Don't call solib_create_inferior_hook, call post_create_inferior if a new inferior was created. * jit.c (maint_info_jit_cmd): New. (_initialize_jit): Register new command. * linux-nat.c (linux_nat_target::follow_fork): Don't call check_for_thread_db. * linux-nat.h (check_for_thread_db): Remove declaration. * linux-thread-db.c (check_thread_signals): Make static. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Mention "maint info jit". gdb/testsuite/ChangeLog: * gdb.base/jit-elf-fork-main.c: New test. * gdb.base/jit-elf-fork-solib.c: New test. * gdb.base/jit-elf-fork.exp: New test. Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c |
||
|
Simon Marchi
|
922cc93d5d |
gdb: maintain ptid -> thread map, optimize find_thread_ptid
When debugging a large number of threads (thousands), looking up a thread by ptid_t using the inferior::thread_list linked list can add up. Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and change the find_thread_ptid function to look up a thread using std::unordered_map::find, instead of iterating on all of the inferior's threads. This should make it faster to look up a thread from its ptid. Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c Co-Authored-By: Pedro Alves <pedro@palves.net> |
||
|
Simon Marchi
|
71a2349005 |
gdb: optimize selection of resumed thread with pending event
Consider a case where many threads (thousands) keep hitting a breakpoint whose condition evaluates to false. random_pending_event_thread is responsible for selecting a thread from an inferior among all that are resumed with a pending wait status. It is currently implemented by walking the inferior's thread list twice: once to count the number of candidates and once to select a random one. Since we now maintain a per target list of resumed threads with pending event, we can implement this more efficiently by walking that list and selecting the first thread that matches the criteria (random_pending_event_thread looks for an thread from a specific inferior, and possibly a filter ptid). It will be faster especially in the common case where there isn't any resumed thread with pending event. Currently, we have to iterate the thread list to figure this out. With this patch, the list of resumed threads with pending event will be empty, so it's quick to figure out. The random selection is kept, but is moved to process_stratum_target::random_resumed_with_pending_wait_status. The same technique is used: do a first pass to count the number of candidates, and do a second pass to select a random one. But given that the list of resumed threads with pending wait statuses will generally be short, or at least shorter than the full thread list, it should be quicker. Note that this isn't completely true, in case there are multiple inferiors on the same target. Imagine that inferior A has 10k resumed threads with pending wait statuses, and random_pending_event_thread is called with inferior B. We'll need to go through the list that contains inferior A's threads to realize that inferior B has no resumed threads with pending wait status. But I think that this is a corner / pathological case. And a possible fix for this situation would be to make random_pending_event_thread work per-process-target, rather than per-inferior. Change-Id: I1b71d01beaa500a148b5b9797745103e13917325 |
||
|
Simon Marchi
|
273dadf2c2 |
gdb: optimize check for resumed threads with pending wait status in maybe_set_commit_resumed_all_targets
Consider a test case where many threads (thousands) keep hitting a breakpoint whose condition evaluates to false. maybe_set_commit_resumed_all_targets is called at each handled event, when the scoped_disable_commit_resumed object in fetch_inferior_event is reset_and_commit-ed. One particularly expensive check in there is whether the target has at least one resumed thread with a pending wait status (in which case, we don't want to commit the resumed threads, as we want to consume this status first). It is currently implemented as walking all threads of the target. Since we now maintain a per-target list of resumed threads with pending status, we can do this check efficiently, by checking whether that list is empty or not. Add the process_stratum_target::has_resumed_with_pending_wait_status method for this, and use it in maybe_set_commit_resumed_all_targets. Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6 |
||
|
Simon Marchi
|
1edb66d856 |
gdb: make thread_info::suspend private, add getters / setters
A following patch will want to take some action when a pending wait
status is set on or removed from a thread. Add a getter and a setter on
thread_info for the pending waitstatus, so that we can add some code in
the setter later.
The thing is, the pending wait status field is in the
thread_suspend_state, along with other fields that we need to backup
before and restore after the thread does an inferior function call.
Therefore, make the thread_suspend_state member private
(thread_info::suspend becomes thread_info::m_suspend), and add getters /
setters for all of its fields:
- pending wait status
- stop signal
- stop reason
- stop pc
For the pending wait status, add the additional has_pending_waitstatus
and clear_pending_waitstatus methods.
I think this makes the thread_info interface a bit nicer, because we
now access the fields as:
thread->stop_pc ()
rather than
thread->suspend.stop_pc
The stop_pc field being in the `suspend` structure is an implementation
detail of thread_info that callers don't need to be aware of.
For the backup / restore of the thread_suspend_state structure, add
save_suspend_to and restore_suspend_from methods. You might wonder why
`save_suspend_to`, as opposed to a simple getter like
thread_suspend_state &suspend ();
I want to make it clear that this is to be used only for backing up and
restoring the suspend state, _not_ to access fields like:
thread->suspend ()->stop_pc
Adding some getters / setters allows adding some assertions. I find
that this helps understand how things are supposed to work. Add:
- When getting the pending status (pending_waitstatus method), ensure
that there is a pending status.
- When setting a pending status (set_pending_waitstatus method), ensure
there is no pending status.
There is one case I found where this wasn't true - in
remote_target::process_initial_stop_replies - which needed adjustments
to respect that contract. I think it's because
process_initial_stop_replies is kind of (ab)using the
thread_info::suspend::waitstatus to store some statuses temporarily, for
its internal use (statuses it doesn't intent on leaving pending).
process_initial_stop_replies pulls out stop replies received during the
initial connection using target_wait. It always stores the received
event in `evthread->suspend.waitstatus`. But it only sets
waitstatus_pending_p, if it deems the event interesting enough to leave
pending, to be reported to the core:
if (ws.kind != TARGET_WAITKIND_STOPPED
|| ws.value.sig != GDB_SIGNAL_0)
evthread->suspend.waitstatus_pending_p = 1;
It later uses this flag a bit below, to choose which thread to make the
"selected" one:
if (selected == NULL
&& thread->suspend.waitstatus_pending_p)
selected = thread;
And ultimately that's used if the user-visible mode is all-stop, so that
we print the stop for that interesting thread:
/* In all-stop, we only print the status of one thread, and leave
others with their status pending. */
if (!non_stop)
{
thread_info *thread = selected;
if (thread == NULL)
thread = lowest_stopped;
if (thread == NULL)
thread = first;
print_one_stopped_thread (thread);
}
But in any case (all-stop or non-stop), print_one_stopped_thread needs
to access the waitstatus value of these threads that don't have a
pending waitstatus (those that had TARGET_WAITKIND_STOPPED +
GDB_SIGNAL_0). This doesn't work with the assertions I've
put.
So, change the code to only set the thread's wait status if it is an
interesting one that we are going to leave pending. If the thread
stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED +
GDB_SIGNAL_0), don't store it. Adjust print_one_stopped_thread to
understand that if a thread has no pending waitstatus, it's because it
stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0.
The call to set_last_target_status also uses the pending waitstatus.
However, given that the pending waitstatus for the thread may have been
cleared in print_one_stopped_thread (and that there might not even be a
pending waitstatus in the first place, as explained above), it is no
longer possible to do it at this point. To fix that, move the call to
set_last_target_status in print_one_stopped_thread. I think this will
preserve the existing behavior, because set_last_target_status is
currently using the current thread's wait status. And the current
thread is the last one for which print_one_stopped_thread is called. So
by calling set_last_target_status in print_one_stopped_thread, we'll get
the same result. set_last_target_status will possibly be called
multiple times, but only the last call will matter. It just means
possibly more calls to set_last_target_status, but those are cheap.
Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7
|
||
|
Simon Marchi
|
7846f3aa61 |
gdb: add setter / getter for thread_info resumed state
A following patch will want to do things when a thread's resumed state changes. Make the `resumed` field private (renamed to `m_resumed`) and add a getter and a setter for it. The following patch in question will therefore be able to add some code to the setter. Change-Id: I360c48cc55a036503174313261ce4e757d795319 |
||
|
Simon Marchi
|
8b6a69b2f3 |
gdb: use intrusive list for step-over chain
The threads that need a step-over are currently linked using an hand-written intrusive doubly-linked list, so that seems a very good candidate for intrusive_list, convert it. For this, we have a use case of appending a list to another one (in start_step_over). Based on the std::list and Boost APIs, add a splice method. However, only support splicing the other list at the end of the `this` list, since that's all we need. Add explicit default assignment operators to reference_to_pointer_iterator, which are otherwise implicitly deleted. This is needed because to define thread_step_over_list_safe_iterator, we wrap reference_to_pointer_iterator inside a basic_safe_iterator, and basic_safe_iterator needs to be able to copy-assign the wrapped iterator. The move-assignment operator is therefore not needed, only the copy-assignment operator is. But for completeness, add both. Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c |
||
|
Pedro Alves
|
08bdefb58b |
gdb: make inferior_list use intrusive_list
Change inferior_list, the global list of inferiors, to use intrusive_list. I think most other changes are somewhat obvious fallouts from this change. There is a small change in behavior in scoped_mock_context. Before this patch, constructing a scoped_mock_context would replace the whole inferior list with only the new mock inferior. Tests using two scoped_mock_contexts therefore needed to manually link the two inferiors together, as the second scoped_mock_context would bump the first mock inferior from the thread list. With this patch, a scoped_mock_context adds its mock inferior to the inferior list on construction, and removes it on destruction. This means that tests run with mock inferiors in the inferior list in addition to any pre-existing inferiors (there is always at least one). There is no possible pid clash problem, since each scoped mock inferior uses its own process target, and pids are per process target. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018 |
||
|
Lancelot SIX
|
22b11ba924 |
Remove unused parameter in maybe_software_singlestep
While working around, I noticed that the last parameter of maybe_software_singlestep is never used. This path removes it. Built on x86_64-linux-gnu and riscv64-linux-gnu. gdb/ChangeLog: * infrun.c (maybe_software_singlestep): Remove unused PC parameter. (resume_1): Update calls to maybe_software_singlestep. |
||
|
Simon Marchi
|
ac0d67ed1d |
gdb: remove unnecessary parameter wait_ptid from do_target_wait
do_target_wait has a wait_ptid parameter, to filter what ptid we wait on. The sole caller of do_target_wait passes minus_one_ptid, meaning "all ptids". So in practice, this parameter is not needed, remove it. gdb/ChangeLog: * infrun.c (do_target_wait): Remove wait_ptid parameter. (fetch_inferior_event): Adjust. Change-Id: I54119beb43db678e4b2081dc490f89e7ff878e74 |
||
|
Simon Marchi
|
122373f7f2 |
gdb: try to load libthread_db only after reading all shared libraries when attaching / handling a fork child
When trying to attach to a pthread process on a Linux system with glibc 2.33,
we get:
$ ./gdb -q -nx --data-directory=data-directory -p 1472010
Attaching to process 1472010
[New LWP 1472013]
[New LWP 1472014]
[New LWP 1472015]
Error while reading shared library symbols for /usr/lib/libpthread.so.0:
Cannot find user-level thread for LWP 1472015: generic error
0x00007ffff6d3637f in poll () from /usr/lib/libc.so.6
(gdb)
When attaching to a process (or handling a fork child, an operation very
similar to attaching), GDB reads the shared library list from the
process. For each shared library (if "set auto-solib-add" is on), it
reads its symbols and calls the "new_objfile" observable.
The libthread-db code monitors this observable, and if it sees an
objfile named somewhat like "libpthread.so" go by, it tries to load
libthread_db.so in the GDB process itself. libthread_db knows how to
navigate libpthread's data structures to get information about the
existing threads.
To locate these data structures, libthread_db calls ps_pglobal_lookup
(implemented in proc-service.c), passing in a symbol name and expecting
an address in return.
Before glibc 2.33, libthread_db always asked for symbols found in
libpthread. There was no ordering problem: since we were always trying
to load libthread_db in reaction to processing libpthread (and reading
in its symbols) and libthread_db only asked symbols from libpthread, the
requested symbols could always be found. Starting with glibc 2.33,
libthread_db now asks for a symbol name that can be found in
/lib/ld-linux-x86-64.so.2 (_rtld_global). And the ordering in which GDB
reads the shared libraries from the inferior when attaching is
unfortunate, in that libpthread is processed before ld-linux. So when
loading libthread_db in reaction to processing libpthread, and
libthread_db requests the symbol that is from ld-linux, GDB is not yet
able to supply it.
That problematic symbol lookup happens in the thread_from_lwp function,
when we call td_ta_map_lwp2thr_p, and an exception is thrown at this
point:
#0 0x00007ffff6681012 in __cxxabiv1::__cxa_throw (obj=0x60e000006100, tinfo=0x555560033b50 <typeinfo for gdb_exception_error>, dest=0x55555d9404bc <gdb_exception_error::~gdb_exception_error()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:78
#1 0x000055555e5d3734 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", ap=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdbsupport/common-exceptions.cc:200
#2 0x000055555e5d37d4 in throw_verror (error=GENERIC_ERROR, fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", ap=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdbsupport/common-exceptions.cc:208
#3 0x000055555e0b0ed2 in verror (string=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", args=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdb/utils.c:171
#4 0x000055555e5e898a in error (fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43
#5 0x000055555d06b4bc in thread_from_lwp (stopped=0x617000035d80, ptid=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:418
#6 0x000055555d07040d in try_thread_db_load_1 (info=0x60c000011140) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:912
#7 0x000055555d071103 in try_thread_db_load (library=0x55555f0c62a0 "libthread_db.so.1", check_auto_load_safe=false) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1014
#8 0x000055555d072168 in try_thread_db_load_from_sdir () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1091
#9 0x000055555d072d1c in thread_db_load_search () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1146
#10 0x000055555d07365c in thread_db_load () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1203
#11 0x000055555d07373e in check_for_thread_db () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1246
#12 0x000055555d0738ab in thread_db_new_objfile (objfile=0x61300000c0c0) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1275
#13 0x000055555bd10740 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x616000068d88: 0x55555d073745 <thread_db_new_objfile(objfile*)>) at /usr/include/c++/10.2.0/bits/invoke.h:60
#14 0x000055555bd02096 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x616000068d88: 0x55555d073745 <thread_db_new_objfile(objfile*)>) at /usr/include/c++/10.2.0/bits/invoke.h:153
#15 0x000055555bce0392 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffb4a0: 0x61300000c0c0) at /usr/include/c++/10.2.0/bits/std_function.h:291
#16 0x000055555d3595c0 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x616000068d88, __args#0=0x61300000c0c0) at /usr/include/c++/10.2.0/bits/std_function.h:622
#17 0x000055555d356b7f in gdb::observers::observable<objfile*>::notify (this=0x555566727020 <gdb::observers::new_objfile>, args#0=0x61300000c0c0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:106
#18 0x000055555da3f228 in symbol_file_add_with_addrs (abfd=0x61200001ccc0, name=0x6190000d9090 "/usr/lib/libpthread.so.0", add_flags=..., addrs=0x7fffffffbc10, flags=..., parent=0x0) at /home/simark/src/binutils-gdb/gdb/symfile.c:1131
#19 0x000055555da3f763 in symbol_file_add_from_bfd (abfd=0x61200001ccc0, name=0x6190000d9090 "/usr/lib/libpthread.so.0", add_flags=<error reading variable: Cannot access memory at address 0xffffffffffffffb0>, addrs=0x7fffffffbc10, flags=<error reading variable: Cannot access memory at address 0xffffffffffffffc0>, parent=0x0) at /home/simark/src/binutils-gdb/gdb/symfile.c:1167
#20 0x000055555d95f9fa in solib_read_symbols (so=0x6190000d8e80, flags=...) at /home/simark/src/binutils-gdb/gdb/solib.c:681
#21 0x000055555d96233d in solib_add (pattern=0x0, from_tty=0, readsyms=1) at /home/simark/src/binutils-gdb/gdb/solib.c:987
#22 0x000055555d93646e in enable_break (info=0x608000008f20, from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2238
#23 0x000055555d93cfc0 in svr4_solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:3049
#24 0x000055555d96610d in solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib.c:1195
#25 0x000055555cdee318 in post_create_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:318
#26 0x000055555ce00e6e in setup_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:2439
#27 0x000055555ce59c34 in handle_one (event=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:4887
#28 0x000055555ce5cd00 in stop_all_threads () at /home/simark/src/binutils-gdb/gdb/infrun.c:5064
#29 0x000055555ce7f0da in stop_waiting (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:8006
#30 0x000055555ce67f5c in handle_signal_stop (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:6062
#31 0x000055555ce63653 in handle_inferior_event (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:5727
#32 0x000055555ce4f297 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4105
#33 0x000055555cdbe3bf in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42
#34 0x000055555d018047 in handle_target_event (error=0, client_data=0x0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:4060
#35 0x000055555e5ea77e in handle_file_event (file_ptr=0x60600008b1c0, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:575
#36 0x000055555e5eb09c in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:701
#37 0x000055555e5e8d19 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212
#38 0x000055555dd6e0d4 in wait_sync_command_done () at /home/simark/src/binutils-gdb/gdb/top.c:528
#39 0x000055555dd6e372 in maybe_wait_sync_command_done (was_sync=0) at /home/simark/src/binutils-gdb/gdb/top.c:545
#40 0x000055555d0ec7c8 in catch_command_errors (command=0x55555ce01bb8 <attach_command(char const*, int)>, arg=0x7fffffffe28d "1472010", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:452
#41 0x000055555d0f03ad in captured_main_1 (context=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1149
#42 0x000055555d0f1239 in captured_main (data=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1232
#43 0x000055555d0f1315 in gdb_main (args=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1257
#44 0x000055555bb70cf9 in main (argc=7, argv=0x7fffffffde88) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
The exception is caught here:
#0 __cxxabiv1::__cxa_begin_catch (exc_obj_in=0x60e0000060e0) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_catch.cc:84
#1 0x000055555d95fded in solib_read_symbols (so=0x6190000d8e80, flags=...) at /home/simark/src/binutils-gdb/gdb/solib.c:689
#2 0x000055555d96233d in solib_add (pattern=0x0, from_tty=0, readsyms=1) at /home/simark/src/binutils-gdb/gdb/solib.c:987
#3 0x000055555d93646e in enable_break (info=0x608000008f20, from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2238
#4 0x000055555d93cfc0 in svr4_solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:3049
#5 0x000055555d96610d in solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib.c:1195
#6 0x000055555cdee318 in post_create_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:318
#7 0x000055555ce00e6e in setup_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:2439
#8 0x000055555ce59c34 in handle_one (event=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:4887
#9 0x000055555ce5cd00 in stop_all_threads () at /home/simark/src/binutils-gdb/gdb/infrun.c:5064
#10 0x000055555ce7f0da in stop_waiting (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:8006
#11 0x000055555ce67f5c in handle_signal_stop (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:6062
#12 0x000055555ce63653 in handle_inferior_event (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:5727
#13 0x000055555ce4f297 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4105
#14 0x000055555cdbe3bf in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42
#15 0x000055555d018047 in handle_target_event (error=0, client_data=0x0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:4060
#16 0x000055555e5ea77e in handle_file_event (file_ptr=0x60600008b1c0, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:575
#17 0x000055555e5eb09c in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:701
#18 0x000055555e5e8d19 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212
#19 0x000055555dd6e0d4 in wait_sync_command_done () at /home/simark/src/binutils-gdb/gdb/top.c:528
#20 0x000055555dd6e372 in maybe_wait_sync_command_done (was_sync=0) at /home/simark/src/binutils-gdb/gdb/top.c:545
#21 0x000055555d0ec7c8 in catch_command_errors (command=0x55555ce01bb8 <attach_command(char const*, int)>, arg=0x7fffffffe28d "1472010", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:452
#22 0x000055555d0f03ad in captured_main_1 (context=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1149
#23 0x000055555d0f1239 in captured_main (data=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1232
#24 0x000055555d0f1315 in gdb_main (args=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1257
#25 0x000055555bb70cf9 in main (argc=7, argv=0x7fffffffde88) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Catching the exception at this point means that the thread_db_info
object for this inferior will be left in place, despite the failure to
load libthread_db. This means that there won't be further attempts at
loading libthread_db, because thread_db_load will think that
libthread_db is already loaded for this inferior and will always exit
early. To fix this, add a try/catch around calling try_thread_db_load_1
in try_thread_db_load, such that if some exception is thrown while
trying to load libthread_db, we reset / delete the thread_db_info for
that inferior. That alone makes attach work fine again, because
check_for_thread_db is called again in the thread_db_inferior_created
observer (that happens after we learned about all shared libraries and
their symbols), and libthread_db is successfully loaded then.
When attaching, I think that the inferior_created observer is a good
place to try to load libthread_db: it is called once everything has
stabilized, when we learned about all shared libraries.
The only problem then is that when we first try (and fail) to load
libthread_db, in reaction to learning about libpthread, we show this
warning:
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
This is misleading, because we do succeed in loading it later. So when
attaching, I think we shouldn't try to load libthread_db in reaction to
the new_objfile events, we should wait until we have learned about all
shared libraries (using the inferior_created observable). To do so, add
an `in_initial_library_scan` flag to struct inferior. This flag is used
to postpone loading libthread_db if we are attaching or handling a fork
child.
When debugging remotely with GDBserver, the same problem happens, except
that the qSymbol mechanism (allowing the remote side to ask GDB for
symbols values) is involved. The fix there is the same idea, we make
GDB wait until all shared libraries and their symbols are known before
sending out a qSymbol packet. This way, we never present the remote
side a state where libpthread.so's symbols are known but ld-linux's
symbols aren't.
gdb/ChangeLog:
* inferior.h (class inferior) <in_initial_library_scan>: New.
* infcmd.c (post_create_inferior): Set in_initial_library_scan.
* infrun.c (follow_fork_inferior): Likewise.
* linux-thread-db.c (try_thread_db_load): Catch exception thrown
by try_thread_db_load_1
(thread_db_load): Return early if in_initial_library_scan is
set.
* remote.c (remote_new_objfile): Return early if
in_initial_library_scan is set.
Change-Id: I7a279836cfbb2b362b4fde11b196b4aab82f5efb
|
||
|
John Baldwin
|
aeeb758df5 |
Conditionally restore displaced stepping state after fork.
There is no default method for gdbarch_displaced_step_restore_all_in_ptid, so calling it unconditionally for fork events triggered an assertion failure on platforms that do not support displaced stepping. To fix, only invoke the method if the gdbarch supports displaced stepping. Note that not all gdbarches support both displaced stepping and fork events, so gdbarch validation does not require gdbarch_displaced_step_restore_all_in_ptid for any gdbarch supporting displaced stepping. However, the internal assertion in gdbarch_displaced_step_restore_all_in_ptid should catch any gdbarches which do support both but fail to provide this method. gdb/ChangeLog: * infrun.c (handle_inferior_event): Only call gdbarch_displaced_step_restore_all_in_ptid if gdbarch_supports_displaced_stepping is true. |
||
|
Simon Marchi
|
24b21115f5 |
gdb: fix tab after space indentation issues
I spotted some indentation issues where we had some spaces followed by tabs at beginning of line, that I wanted to fix. So while at it, I did a quick grep to find and fix all I could find. gdb/ChangeLog: * Fix tab after space indentation issues throughout. Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd |
||
|
Simon Marchi
|
e0f25bd971 |
gdb: make add_info_alias accept target as a cmd_list_element
Same idea as previous patch, but for add_info_alias. gdb/ChangeLog: * command.h (add_info_alias): Accept target as cmd_list_element. Update callers. Change-Id: If830d423364bf42d7bea5ac4dd3a81adcfce6f7a |
||
|
Simon Marchi
|
294c36eb6a |
gdb: on exec, delegate pushing / unpushing target and adding thread to target_ops::follow_exec
On "exec", some targets need to unpush themselves from the inferior, and do some bookkeeping, like forgetting the data associated to the exec'ing inferior. One such example is the thread-db target. It does so in a special case in thread_db_target::wait, just before returning the TARGET_WAITKIND_EXECD event to its caller. We have another such case in the context of rocm-gdb [1], where the "rocm" target is pushed on top of the linux-nat target. When an exec happens, we want to unpush the rocm target from the exec'ing inferior to close some file descriptors that refer to the pre-exec address space and forget about that inferior. We then want to push the target on the inferior in which execution continues, to open the file descriptors for the post-exec address space. I think that a good way to address this cleanly is to do all this in the target_ops::follow_exec implementations. Make the process_stratum_target::follow_exec implementation have the default behavior of pushing itself to the new inferior's target stack (if execution continues in a new inferior) and add the initial thread. remote_target::follow_exec is an example of process target that wants to do a bit more than the default behavior. So it calls process_stratum_target::follow_exec first and does the extra work second. linux-thread-db (a non-process target) implements follow_exec to do some bookeeping (forget about that process' data), before handing down the event down to the process target (which hits process_stratum_target::follow_exec). gdb/ChangeLog: * target.h (struct target_ops) <follow_exec>: Add ptid_t parameter. (target_follow_exec): Likewise. * target.c (target_follow_exec): Add ptid_t parameter. * infrun.c (follow_exec): Adjust call to target_follow_exec, don't push target nor create thread. * linux-thread-db.c (class thread_db_target) <follow_exec>: New. (thread_db_target::wait): Just return on TARGET_WAITKIND_EXECD. (thread_db_target::follow_exec): New. * remote.c (class remote_target) <follow_exec>: Add ptid_t parameter. (remote_target::follow_exec): Call process_stratum_target::follow_exec. * target-delegates.c: Re-generate. Change-Id: I3f96d0ba3ea0dde6540b7e1b4d5cdb01635088c8 |
||
|
Simon Marchi
|
2af87c859f |
gdb: call target_follow_exec when "set follow-exec-mode" is "same"
target_follow_exec is currently only called in the "follow-exec-mode ==
new" branch of follow_exec, not the "follow-exec-mode == same" branch.
I think it would make sense to call it regardless of the mode to let
targets do some necessary handling.
This is needed in the context of rocm-gdb [1], where a target is pushed
on top of the linux-nat target. On exec, it needs to do some
bookkeeping, close some file descriptors / handles that were related to
the process pre-exec and open some new ones for the process post-exec.
However, by looking at the only in-tree implementation of
target_ops::follow_exec, remote_target::follow_exec, I found that it
would be useful for the extended-remote target too, to align its
behavior with native debugging (although I think that behavior is not
very user-friendly, see PR 27745 [2]).
Using two programs, one (let's call it "execer") that execs the other
(let's call it "execee"), with native:
$ ./gdb -q -nx --data-directory=data-directory ./execer
Reading symbols from ./execer...
(gdb) r
Starting program: /home/simark/build/binutils-gdb/gdb/execer
I am execer
process 1495622 is executing new program: /home/simark/build/binutils-gdb/gdb/execee
I am execee
[Inferior 1 (process 1495622) exited normally]
(gdb) r
Starting program: /home/simark/build/binutils-gdb/gdb/execee
I am execee
[Inferior 1 (process 1495626) exited normally]
And now with gdbserver (some irrelevant output lines removed for brevity):
$ ./gdbserver --once --multi :1234
...
$ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234"
Reading symbols from ./execer...
Remote debugging using :1234
(gdb) r
Starting program: /home/simark/build/binutils-gdb/gdb/execer
process 1495724 is executing new program: /home/simark/build/binutils-gdb/gdb/execee
[Inferior 1 (process 1495724) exited normally]
(gdb) r
`target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols.
Starting program: target:/home/simark/build/binutils-gdb/gdb/execee
warning: Build ID mismatch between current exec-file target:/home/simark/build/binutils-gdb/gdb/execee
and automatically determined exec-file target:/home/simark/build/binutils-gdb/gdb/execer
exec-file-mismatch handling is currently "ask"
Reading /home/simark/build/binutils-gdb/gdb/execer from remote target...
Load new symbol table from "target:/home/simark/build/binutils-gdb/gdb/execer"? (y or n)
When handling the exec, GDB updates the exec-file of the inferior to be
the execee. This means that a subsequent "run" will run the execee, not
the original executable (execer).
remote_target::follow_exec is meant to update the "remote exec-file",
which is the file on the remote system that will be executed if you
"run" the inferior, to the execee as well. However, this is not called
when follow-exec-mode is same, because target_follow_exec is not called
in this branch. As a result, GDB thinks the inferior is executing
execee but the remote side is really executing execer, hence the
mismatch message.
By calling target_follow_exec in the "same" branch of the follow_exec
function, we ensure that everybody agrees, and we get the same behavior
with the extended-remote target as we get with the native target, the
execee is executed on the second run:
$ ./gdbserver --once --multi :1234
...
$ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234"
Reading symbols from ./execer...
Remote debugging using :1234
(gdb) r
Starting program: /home/simark/build/binutils-gdb/gdb/execer
process 1501445 is executing new program: /home/simark/build/binutils-gdb/gdb/execee
[Inferior 1 (process 1501445) exited normally]
(gdb) r
`target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols.
Starting program: target:/home/simark/build/binutils-gdb/gdb/execee
[Inferior 1 (process 1501447) exited normally]
(gdb)
This scenario is tested in gdb.base/foll-exec-mode.exp, and in fact this
patch fixes the test for me when using
--target_board=native-extended-gdbserver.
gdb/ChangeLog:
* infrun.c (follow_exec): Call target_follow_fork when
follow-exec-mode is same.
* target.h (target_follow_fork): Improve doc.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=27745
Change-Id: I4ee84a875e39bf3f8eaf3e6789a4bfe23a2a430e
|
||
|
Simon Marchi
|
89ba430c6b |
gdb: move some variables to an inner scope in save_waitstatus
These two variables:
struct regcache *regcache = get_thread_regcache (tp);
const address_space *aspace = regcache->aspace ();
are only needed inside the "if". Getting a thread's regcache is a
somewhat expensive operation, so it's good to avoid it if not necessary.
Move the variable declarations and their initialization to the "if"
scope.
gdb/ChangeLog:
* infrun.c (save_waitstatus): Move variables to inner scope.
Change-Id: Ief1463728755b4dcc142c0a0a76896e9d594ae84
|
||
|
Simon Marchi
|
c90e7d6352 |
gdbsupport, gdb: give names to observers
Give a name to each observer, this will help produce more meaningful debug message. gdbsupport/ChangeLog: * observable.h (class observable) <struct observer> <observer>: Add name parameter. <name>: New field. <attach>: Add name parameter, update all callers. Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0 |
||
|
Simon Marchi
|
e97007b64a |
gdb: make target_ops::follow_fork return void
I noticed that all implementations return false, so target_ops::follow_fork doesn't really need to return a value. Change it to return void. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Return void. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * infrun.c (follow_fork_inferior): Adjust. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Return void. * fbsd-nat.c (fbsd_nat_target:::follow_fork): Likewise. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Return void. * obsd-nat.h (class obsd_nat_target) <follow_fork>: Return void. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. * remote.c (class remote_target) <follow_fork>: Likewise. (remote_target::follow_fork): Likewise. * target-delegates.c: Re-generate. Change-Id: If908c2f68b29fa275be2b0b9deb41e4c6a1b7879 |
||
|
Simon Marchi
|
b4b1a226df |
gdb: defer commit resume until all available events are consumed
Rationale
---------
Let's say you have multiple threads hitting a conditional breakpoint
at the same time, and all of these are going to evaluate to false.
All these threads will need to be resumed.
Currently, GDB fetches one target event (one SIGTRAP representing the
breakpoint hit) and decides that the thread should be resumed. It
calls resume and commit_resume immediately. It then fetches the
second target event, and does the same, until it went through all
threads.
The result is therefore something like:
- consume event for thread A
- resume thread A
- commit resume (affects thread A)
- consume event for thread B
- resume thread B
- commit resume (affects thread B)
- consume event for thread C
- resume thread C
- commit resume (affects thread C)
For targets where it's beneficial to group resumptions requests (most
likely those that implement target_ops::commit_resume), it would be
much better to have:
- consume event for thread A
- resume thread A
- consume event for thread B
- resume thread B
- consume event for thread C
- resume thread C
- commit resume (affects threads A, B and C)
Implementation details
----------------------
To achieve this, this patch adds another check in
maybe_set_commit_resumed_all_targets to avoid setting the
commit-resumed flag of targets that readily have events to provide to
infrun.
To determine if a target has events readily available to report, this
patch adds an `has_pending_events` target_ops method. The method
returns a simple bool to say whether or not it has pending events to
report.
Testing
=======
To test this, I start GDBserver with a program that spawns multiple
threads:
$ ../gdbserver/gdbserver --once :1234 ~/src/many-threads-stepping-over-breakpoints/many-threads-stepping-over-breakpoints
I then connect with GDB and install a conditional breakpoint that always
evaluates to false (and force the evaluation to be done by GDB):
$ ./gdb -nx --data-directory=data-directory \
/home/simark/src/many-threads-stepping-over-breakpoints/many-threads-stepping-over-breakpoints \
-ex "set breakpoint condition-evaluation host" \
-ex "set pag off" \
-ex "set confirm off" \
-ex "maint set target-non-stop on" \
-ex "tar rem :1234" \
-ex "tb main" \
-ex "b 13 if 0" \
-ex c \
-ex "set debug infrun" \
-ex "set debug remote 1" \
-ex "set debug displaced"
I then do "continue" and look at the log.
The remote target receives a bunch of stop notifications for all
threads that have hit the breakpoint. infrun consumes and processes
one event, decides it should not cause a stop, prepares a displaced
step, after which we should see:
[infrun] maybe_set_commit_resumed_all_process_targets: not requesting commit-resumed for target remote, target has pending events
Same for a second thread (since we have 2 displaced step buffers).
For the following threads, their displaced step is deferred since
there are no more buffers available.
After consuming the last event the remote target has to offer, we get:
[infrun] maybe_set_commit_resumed_all_process_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_process_targets: calling commit_resumed for target remote
[remote] Sending packet: $vCont;s:p14d16b.14d1b1;s:p14d16b.14d1b2#55
[remote] Packet received: OK
Without the patch, there would have been one vCont;s just after each
prepared displaced step.
gdb/ChangeLog:
yyyy-mm-dd Simon Marchi <simon.marchi@efficios.com>
Pedro Alves <pedro@palves.net>
* async-event.c (async_event_handler_marked): New.
* async-event.h (async_event_handler_marked): Declare.
* infrun.c (maybe_set_commit_resumed_all_targets): Switch to
inferior before calling target method. Don't commit-resumed if
target_has_pending_events is true.
* remote.c (remote_target::has_pending_events): New.
* target-delegates.c: Regenerate.
* target.c (target_has_pending_events): New.
* target.h (target_ops::has_pending_events): New target method.
(target_has_pending_events): New.
Change-Id: I18112ba19a1ff4986530c660f530d847bb4a1f1d
|
||
|
Simon Marchi
|
1192f124a3 |
gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
The rationale for this patch comes from the ROCm port [1], the goal
being to reduce the number of back and forths between GDB and the
target when doing successive operations. I'll start with explaining
the rationale and then go over the implementation. In the ROCm / GPU
world, the term "wave" is somewhat equivalent to a "thread" in GDB.
So if you read if from a GPU stand point, just s/thread/wave/.
ROCdbgapi, the library used by GDB [2] to communicate with the GPU
target, gives the illusion that it's possible for the debugger to
control (start and stop) individual threads. But in reality, this is
not how it works. Under the hood, all threads of a queue are
controlled as a group. To stop one thread in a group of running ones,
the state of all threads is retrieved from the GPU, all threads are
destroyed, and all threads but the one we want to stop are re-created
from the saved state. The net result, from the point of view of GDB,
is that the library stopped one thread. The same thing goes if we
want to resume one thread while others are running: the state of all
running threads is retrieved from the GPU, they are all destroyed, and
they are all re-created, including the thread we want to resume.
This leads to some inefficiencies when combined with how GDB works,
here are two examples:
- Stopping all threads: because the target operates in non-stop mode,
when the user interface mode is all-stop, GDB must stop all threads
individually when presenting a stop. Let's suppose we have 1000
threads and the user does ^C. GDB asks the target to stop one
thread. Behind the scenes, the library retrieves 1000 thread
states and restores the 999 others still running ones. GDB asks
the target to stop another one. The target retrieves 999 thread
states and restores the 998 remaining ones. That means that to
stop 1000 threads, we did 1000 back and forths with the GPU. It
would have been much better to just retrieve the states once and
stop there.
- Resuming with pending events: suppose the 1000 threads hit a
breakpoint at the same time. The breakpoint is conditional and
evaluates to true for the first thread, to false for all others.
GDB pulls one event (for the first thread) from the target, decides
that it should present a stop, so stops all threads using
stop_all_threads. All these other threads have a breakpoint event
to report, which is saved in `thread_info::suspend::waitstatus` for
later. When the user does "continue", GDB resumes that one thread
that did hit the breakpoint. It then processes the pending events
one by one as if they just arrived. It picks one, evaluates the
condition to false, and resumes the thread. It picks another one,
evaluates the condition to false, and resumes the thread. And so
on. In between each resumption, there is a full state retrieval
and re-creation. It would be much nicer if we could wait a little
bit before sending those threads on the GPU, until it processed all
those pending events.
To address this kind of performance issue, ROCdbgapi has a concept
called "forward progress required", which is a boolean state that
allows its user (i.e. GDB) to say "I'm doing a bunch of operations,
you can hold off putting the threads on the GPU until I'm done" (the
"forward progress not required" state). Turning forward progress back
on indicates to the library that all threads that are supposed to be
running should now be really running on the GPU.
It turns out that GDB has a similar concept, though not as general,
commit_resume. One difference is that commit_resume is not stateful:
the target can't look up "does the core need me to schedule resumed
threads for execution right now". It is also specifically linked to
the resume method, it is not used in other contexts. The target
accumulates resumption requests through target_ops::resume calls, and
then commits those resumptions when target_ops::commit_resume is
called. The target has no way to check if it's ok to leave resumed
threads stopped in other target methods.
To bridge the gap, this patch generalizes the commit_resume concept in
GDB to match the forward progress concept of ROCdbgapi. The current
name (commit_resume) can be interpreted as "commit the previous resume
calls". I renamed the concept to "commit_resumed", as in "commit the
threads that are resumed".
In the new version, we have two things:
- the commit_resumed_state field in process_stratum_target: indicates
whether GDB requires target stacks using this target to have
resumed threads committed to the execution target/device. If
false, an execution target is allowed to leave resumed threads
un-committed at the end of whatever method it is executing.
- the commit_resumed target method: called when commit_resumed_state
transitions from false to true. While commit_resumed_state was
false, the target may have left some resumed threads un-committed.
This method being called tells it that it should commit them back
to the execution device.
Let's take the "Stopping all threads" scenario from above and see how
it would work with the ROCm target with this change. Before stopping
all threads, GDB would set the target's commit_resumed_state field to
false. It would then ask the target to stop the first thread. The
target would retrieve all threads' state from the GPU and mark that
one as stopped. Since commit_resumed_state is false, it leaves all
the other threads (still resumed) stopped. GDB would then proceed to
call target_stop for all the other threads. Since resumed threads are
not committed, this doesn't do any back and forth with the GPU.
To simplify the implementation of targets, this patch makes it so that
when calling certain target methods, the contract between the core and
the targets guarantees that commit_resumed_state is false. This way,
the target doesn't need two paths, one for commit_resumed_state ==
true and one for commit_resumed_state == false. It can just assert
that commit_resumed_state is false and work with that assumption.
This also helps catch places where we forgot to disable
commit_resumed_state before calling the method, which represents a
probable optimization opportunity. The commit adds assertions in the
target method wrappers (target_resume and friends) to have some
confidence that this contract between the core and the targets is
respected.
The scoped_disable_commit_resumed type is used to disable the commit
resumed state of all process targets on construction, and selectively
re-enable it on destruction (see below for criteria). Note that it
only sets the process_stratum_target::commit_resumed_state flag. A
subsequent call to maybe_call_commit_resumed_all_targets is necessary
to call the commit_resumed method on all target stacks with process
targets that got their commit_resumed_state flag turned back on. This
separation is because we don't want to call the commit_resumed methods
in scoped_disable_commit_resumed's destructor, as they may throw.
On destruction, commit-resumed is not re-enabled for a given target
if:
1. this target has no threads resumed, or
2. this target has at least one resumed thread with a pending status
known to the core (saved in thread_info::suspend::waitstatus).
The first point is not technically necessary, because a proper
commit_resumed implementation would be a no-op if the target has no
resumed threads. But since we have a flag do to a quick check, it
shouldn't hurt.
The second point is more important: together with the
scoped_disable_commit_resumed instance added in fetch_inferior_event,
it makes it so the "Resuming with pending events" described above is
handled efficiently. Here's what happens in that case:
1. The user types "continue".
2. Upon destruction, the scoped_disable_commit_resumed in the
`proceed` function does not enable commit-resumed, as it sees some
threads have pending statuses.
3. fetch_inferior_event is called to handle another event, the
breakpoint hit evaluates to false, and that thread is resumed.
Because there are still more threads with pending statuses, the
destructor of scoped_disable_commit_resumed in
fetch_inferior_event still doesn't enable commit-resumed.
4. Rinse and repeat step 3, until the last pending status is handled
by fetch_inferior_event. In that case,
scoped_disable_commit_resumed's destructor sees there are no more
threads with pending statues, so it asks the target to commit
resumed threads.
This allows us to avoid all unnecessary back and forths, there is a
single commit_resumed call once all pending statuses are processed.
This change required remote_target::remote_stop_ns to learn how to
handle stopping threads that were resumed but pending vCont. The
simplest example where that happens is when using the remote target in
all-stop, but with "maint set target-non-stop on", to force it to
operate in non-stop mode under the hood. If two threads hit a
breakpoint at the same time, GDB will receive two stop replies. It
will present the stop for one thread and save the other one in
thread_info::suspend::waitstatus.
Before this patch, when doing "continue", GDB first resumes the thread
without a pending status:
Sending packet: $vCont;c:p172651.172676#f3
It then consumes the pending status in the next fetch_inferior_event
call:
[infrun] do_target_wait_1: Using pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP for Thread 1517137.1517137.
[infrun] target_wait (-1.0.0, status) =
[infrun] 1517137.1517137.0 [Thread 1517137.1517137],
[infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP
It then realizes it needs to stop all threads to present the stop, so
stops the thread it just resumed:
[infrun] stop_all_threads: Thread 1517137.1517137 not executing
[infrun] stop_all_threads: Thread 1517137.1517174 executing, need stop
remote_stop called
Sending packet: $vCont;t:p172651.172676#04
This is an unnecessary resume/stop. With this patch, we don't commit
resumed threads after proceeding, because of the pending status:
[infrun] maybe_commit_resumed_all_process_targets: not requesting commit-resumed for target extended-remote, a thread has a pending waitstatus
When GDB handles the pending status and stop_all_threads runs, we stop a
resumed but pending vCont thread:
remote_stop_ns: Enqueueing phony stop reply for thread pending vCont-resume (1520940, 1520976, 0)
That thread was never actually resumed on the remote stub / gdbserver,
so we shouldn't send a packet to the remote side asking to stop the
thread.
Note that there are paths that resume the target and then do a
synchronous blocking wait, in sort of nested event loop, via
wait_sync_command_done. For example, inferior function calls, or any
run control command issued from a breakpoint command list. We handle
that making wait_sync_command_one a "sync" point -- force forward
progress, or IOW, force-enable commit-resumed state.
gdb/ChangeLog:
yyyy-mm-dd Simon Marchi <simon.marchi@efficios.com>
Pedro Alves <pedro@palves.net>
* infcmd.c (run_command_1, attach_command, detach_command)
(interrupt_target_1): Use scoped_disable_commit_resumed.
* infrun.c (do_target_resume): Remove
target_commit_resume call.
(commit_resume_all_targets): Remove.
(maybe_set_commit_resumed_all_targets): New.
(maybe_call_commit_resumed_all_targets): New.
(enable_commit_resumed): New.
(scoped_disable_commit_resumed::scoped_disable_commit_resumed)
(scoped_disable_commit_resumed::~scoped_disable_commit_resumed)
(scoped_disable_commit_resumed::reset)
(scoped_disable_commit_resumed::reset_and_commit)
(scoped_enable_commit_resumed::scoped_enable_commit_resumed)
(scoped_enable_commit_resumed::~scoped_enable_commit_resumed):
New.
(proceed): Use scoped_disable_commit_resumed and
maybe_call_commit_resumed_all_targets.
(fetch_inferior_event): Use scoped_disable_commit_resumed.
* infrun.h (struct scoped_disable_commit_resumed): New.
(maybe_call_commit_resumed_all_process_targets): New.
(struct scoped_enable_commit_resumed): New.
* mi/mi-main.c (exec_continue): Use scoped_disable_commit_resumed.
* process-stratum-target.h (class process_stratum_target):
<commit_resumed_state>: New.
* record-full.c (record_full_wait_1): Change commit_resumed_state
around calling commit_resumed.
* remote.c (class remote_target) <commit_resume>: Rename to...
<commit_resumed>: ... this.
(struct stop_reply): Move up.
(remote_target::commit_resume): Rename to...
(remote_target::commit_resumed): ... this. Check if there is any
thread pending vCont resume.
(remote_target::remote_stop_ns): Generate stop replies for resumed
but pending vCont threads.
(remote_target::wait_ns): Add gdb_assert.
* target-delegates.c: Regenerate.
* target.c (target_wait, target_resume): Assert that the current
process_stratum target isn't in commit-resumed state.
(defer_target_commit_resume): Remove.
(target_commit_resume): Remove.
(target_commit_resumed): New.
(make_scoped_defer_target_commit_resume): Remove.
(target_stop): Assert that the current process_stratum target
isn't in commit-resumed state.
* target.h (struct target_ops) <commit_resume>: Rename to ...
<commit_resumed>: ... this.
(target_commit_resume): Remove.
(target_commit_resumed): New.
(make_scoped_defer_target_commit_resume): Remove.
* top.c (wait_sync_command_done): Use
scoped_enable_commit_resumed.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb/
[2] https://github.com/ROCm-Developer-Tools/ROCdbgapi
Change-Id: I836135531a29214b21695736deb0a81acf8cf566
|
||
|
Simon Marchi
|
328d42d87e |
gdb: remove current_top_target function
The current_top_target function is a hidden dependency on the current inferior. Since I'd like to slowly move towards reducing our dependency on the global current state, remove this function and make callers use current_inferior ()->top_target () There is no expected change in behavior, but this one step towards making those callers use the inferior from their context, rather than refer to the global current inferior. gdb/ChangeLog: * target.h (current_top_target): Remove, make callers use the current inferior instead. * target.c (current_top_target): Remove. Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d |
||
|
Simon Marchi
|
d777bf0df2 |
gdb: move all "current target" wrapper implementations to target.c
The following patch removes the current_top_target function, replacing uses with `current_inferior ()->top_target ()`. This is a problem for uses in target.h, because they don't have access to the current_inferior function and the inferior structure: target.h can't include inferior.h, otherwise that would make a cyclic inclusion. Avoid this by moving all implementations of the wrappers that call target methods with the current target to target.c. Many of them are changed from a macro to a function, which is an improvement for readability and debuggability, IMO. target_shortname and target_longname were not function-like macros, so a few adjustments are needed. gdb/ChangeLog: * target.h (target_shortname): Change to function declaration. (target_longname): Likewise. (target_attach_no_wait): Likewise. (target_post_attach): Likewise. (target_prepare_to_store): Likewise. (target_supports_enable_disable_tracepoint): Likewise. (target_supports_string_tracing): Likewise. (target_supports_evaluation_of_breakpoint_conditions): Likewise. (target_supports_dumpcore): Likewise. (target_dumpcore): Likewise. (target_can_run_breakpoint_commands): Likewise. (target_files_info): Likewise. (target_post_startup_inferior): Likewise. (target_insert_fork_catchpoint): Likewise. (target_remove_fork_catchpoint): Likewise. (target_insert_vfork_catchpoint): Likewise. (target_remove_vfork_catchpoint): Likewise. (target_insert_exec_catchpoint): Likewise. (target_remove_exec_catchpoint): Likewise. (target_set_syscall_catchpoint): Likewise. (target_rcmd): Likewise. (target_can_lock_scheduler): Likewise. (target_can_async_p): Likewise. (target_is_async_p): Likewise. (target_execution_direction): Likewise. (target_extra_thread_info): Likewise. (target_pid_to_exec_file): Likewise. (target_thread_architecture): Likewise. (target_find_memory_regions): Likewise. (target_make_corefile_notes): Likewise. (target_get_bookmark): Likewise. (target_goto_bookmark): Likewise. (target_stopped_by_watchpoint): Likewise. (target_stopped_by_sw_breakpoint): Likewise. (target_supports_stopped_by_sw_breakpoint): Likewise. (target_stopped_by_hw_breakpoint): Likewise. (target_supports_stopped_by_hw_breakpoint): Likewise. (target_have_steppable_watchpoint): Likewise. (target_can_use_hardware_watchpoint): Likewise. (target_region_ok_for_hw_watchpoint): Likewise. (target_can_do_single_step): Likewise. (target_insert_watchpoint): Likewise. (target_remove_watchpoint): Likewise. (target_insert_hw_breakpoint): Likewise. (target_remove_hw_breakpoint): Likewise. (target_can_accel_watchpoint_condition): Likewise. (target_can_execute_reverse): Likewise. (target_get_ada_task_ptid): Likewise. (target_filesystem_is_local): Likewise. (target_trace_init): Likewise. (target_download_tracepoint): Likewise. (target_can_download_tracepoint): Likewise. (target_download_trace_state_variable): Likewise. (target_enable_tracepoint): Likewise. (target_disable_tracepoint): Likewise. (target_trace_start): Likewise. (target_trace_set_readonly_regions): Likewise. (target_get_trace_status): Likewise. (target_get_tracepoint_status): Likewise. (target_trace_stop): Likewise. (target_trace_find): Likewise. (target_get_trace_state_variable_value): Likewise. (target_save_trace_data): Likewise. (target_upload_tracepoints): Likewise. (target_upload_trace_state_variables): Likewise. (target_get_raw_trace_data): Likewise. (target_get_min_fast_tracepoint_insn_len): Likewise. (target_set_disconnected_tracing): Likewise. (target_set_circular_trace_buffer): Likewise. (target_set_trace_buffer_size): Likewise. (target_set_trace_notes): Likewise. (target_get_tib_address): Likewise. (target_set_permissions): Likewise. (target_static_tracepoint_marker_at): Likewise. (target_static_tracepoint_markers_by_strid): Likewise. (target_traceframe_info): Likewise. (target_use_agent): Likewise. (target_can_use_agent): Likewise. (target_augmented_libraries_svr4_read): Likewise. (target_log_command): Likewise. * target.c (target_shortname): New. (target_longname): New. (target_attach_no_wait): New. (target_post_attach): New. (target_prepare_to_store): New. (target_supports_enable_disable_tracepoint): New. (target_supports_string_tracing): New. (target_supports_evaluation_of_breakpoint_conditions): New. (target_supports_dumpcore): New. (target_dumpcore): New. (target_can_run_breakpoint_commands): New. (target_files_info): New. (target_post_startup_inferior): New. (target_insert_fork_catchpoint): New. (target_remove_fork_catchpoint): New. (target_insert_vfork_catchpoint): New. (target_remove_vfork_catchpoint): New. (target_insert_exec_catchpoint): New. (target_remove_exec_catchpoint): New. (target_set_syscall_catchpoint): New. (target_rcmd): New. (target_can_lock_scheduler): New. (target_can_async_p): New. (target_is_async_p): New. (target_execution_direction): New. (target_extra_thread_info): New. (target_pid_to_exec_file): New. (target_thread_architecture): New. (target_find_memory_regions): New. (target_make_corefile_notes): New. (target_get_bookmark): New. (target_goto_bookmark): New. (target_stopped_by_watchpoint): New. (target_stopped_by_sw_breakpoint): New. (target_supports_stopped_by_sw_breakpoint): New. (target_stopped_by_hw_breakpoint): New. (target_supports_stopped_by_hw_breakpoint): New. (target_have_steppable_watchpoint): New. (target_can_use_hardware_watchpoint): New. (target_region_ok_for_hw_watchpoint): New. (target_can_do_single_step): New. (target_insert_watchpoint): New. (target_remove_watchpoint): New. (target_insert_hw_breakpoint): New. (target_remove_hw_breakpoint): New. (target_can_accel_watchpoint_condition): New. (target_can_execute_reverse): New. (target_get_ada_task_ptid): New. (target_filesystem_is_local): New. (target_trace_init): New. (target_download_tracepoint): New. (target_can_download_tracepoint): New. (target_download_trace_state_variable): New. (target_enable_tracepoint): New. (target_disable_tracepoint): New. (target_trace_start): New. (target_trace_set_readonly_regions): New. (target_get_trace_status): New. (target_get_tracepoint_status): New. (target_trace_stop): New. (target_trace_find): New. (target_get_trace_state_variable_value): New. (target_save_trace_data): New. (target_upload_tracepoints): New. (target_upload_trace_state_variables): New. (target_get_raw_trace_data): New. (target_get_min_fast_tracepoint_insn_len): New. (target_set_disconnected_tracing): New. (target_set_circular_trace_buffer): New. (target_set_trace_buffer_size): New. (target_set_trace_notes): New. (target_get_tib_address): New. (target_set_permissions): New. (target_static_tracepoint_marker_at): New. (target_static_tracepoint_markers_by_strid): New. (target_traceframe_info): New. (target_use_agent): New. (target_can_use_agent): New. (target_augmented_libraries_svr4_read): New. (target_log_command): New. * bfin-tdep.c (bfin_sw_breakpoint_from_kind): Adjust. * infrun.c (set_schedlock_func): Adjust. * mi/mi-main.c (exec_reverse_continue): Adjust. * reverse.c (exec_reverse_once): Adjust. * sh-tdep.c (sh_sw_breakpoint_from_kind): Adjust. * tui/tui-stack.c (tui_locator_window::make_status_line): Adjust. * remote-sim.c (gdbsim_target::detach): Adjust. (gdbsim_target::files_info): Adjust. Change-Id: I72ef56e9a25adeb0b91f1ad05e34c89f77ebeaa8 |
||
|
Simon Marchi
|
02980c5645 |
gdb: remove push_target free functions
Same as the previous patch, but for the push_target functions. The implementation of the move variant is moved to a new overload of inferior::push_target. gdb/ChangeLog: * target.h (push_target): Remove, update callers to use inferior::push_target. * target.c (push_target): Remove. * inferior.h (class inferior) <push_target>: New overload. Change-Id: I5a95496666278b8f3965e5e8aecb76f54a97c185 |
||
|
Simon Marchi
|
f058c5210f |
gdb: remove unneeded argument in check_multi_target_resumption
If we reach the modified line, resume_target is necessarily nullptr, because of the check at the beginning of the function. So we'll necessarily iterate on all non-exited inferiors (across all targets), which is what we want. So just remove the unnecessary argument. gdb/ChangeLog: * infrun.c (check_multi_target_resumption): Remove argument to all_non_exited_inferiors. Change-Id: If95704915dca19599d5f7f4732bbd6ccd20bf6b4 |
||
|
Simon Marchi
|
6b36ddeb1e |
gdb: make async event handlers clear themselves
The `ready` flag of async event handlers is cleared by the async event handler system right before invoking the associated callback, in check_async_event_handlers. This is not ideal with how the infrun subsystem consumes events: all targets' async event handler callbacks essentially just invoke `inferior_event_handler`, which eventually calls `fetch_inferior_event` and `do_target_wait`. `do_target_wait` picks an inferior at random, and thus a target at random (it could be the target whose `ready` flag was cleared, or not), and pulls one event from it. So it's possible that: - the async event handler for a target A is called - we end up consuming an event for target B - all threads of target B are stopped, target_async(0) is called on it, so its async event handler is cleared (e.g. record_btrace_target::async) As a result, target A still has events to report while its async event handler is left unmarked, so these events are not consumed. To counter this, at the end of their async event handler callbacks, targets check if they still have something to report and re-mark their async event handler (e.g. remote_async_inferior_event_handler). The linux_nat target does not suffer from this because it doesn't use an async event handler at the moment. It only uses a pipe registered with the event loop. It is written to in the SIGCHLD handler (and in other spots that want to get target wait method called) and read from in the target's wait method. So if linux_nat happened to be target A in the example above, the pipe would just stay readable, and the event loop would wake up again, until linux_nat's wait method is finally called and consumes the contents of the pipe. I think it would be nicer if targets using async_event_handler worked in a similar way, where the flag would stay set until the target's wait method is actually called. As a first step towards that, this patch moves the responsibility of clearing the ready flags of async event handlers to the invoked callback. All async event handler callbacks are modified to clear their ready flag before doing anything else. So in practice, nothing changes with this patch. It's only the responsibility of clearing the flag that is shifted toward the callee. gdb/ChangeLog: * async-event.h (async_event_handler_func): Add documentation. * async-event.c (check_async_event_handlers): Don't clear async_event_handler ready flag. * infrun.c (infrun_async_inferior_event_handler): Clear ready flag. * record-btrace.c (record_btrace_handle_async_inferior_event): Likewise. * record-full.c (record_full_async_inferior_event_handler): Likewise. * remote-notif.c (remote_async_get_pending_events_handler): Likewise. * remote.c (remote_async_inferior_event_handler): Likewise. Change-Id: I179ef8e99580eae642d332846fd13664dbddc0c1 |