diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2022-01-17 11:27:36 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2022-03-31 13:07:21 -0400 |
commit | 5a0c4a06eb4f4afcf885596ee97706c1045a8476 (patch) | |
tree | 2a857ad7b52063ac2f056ae1de7ddeea0f8018e8 /gdb/source.c | |
parent | 20471e00e2ea400c5a7126a98fb58c6a83b50628 (diff) | |
download | gdb-5a0c4a06eb4f4afcf885596ee97706c1045a8476.zip gdb-5a0c4a06eb4f4afcf885596ee97706c1045a8476.tar.gz gdb-5a0c4a06eb4f4afcf885596ee97706c1045a8476.tar.bz2 |
gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
The check removed by this patch, using current_inferior, looks wrong.
When debugging multiple inferiors with the Linux native target and
linux_handle_extended_wait is called, there's no guarantee about which
is the current inferior. The vfork-done event we receive could be for
any inferior. If the vfork-done event is for a non-current inferior, we
end up wrongfully ignoring it. As a result, the core never processes a
TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
is never cleared, and breakpoints are never reinserted. However,
because the Linux native target decided to ignore the event, it resumed
the thread - while breakpoints out. And that's bad.
The proposed fix is to remove this check. Always report vfork-done
events and let infrun's logic decide if it should be ignored. We don't
save much cycles by filtering the event here.
Add a test that replicates the situation described above. See comments
in the test for more details.
Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
Diffstat (limited to 'gdb/source.c')
0 files changed, 0 insertions, 0 deletions