diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2018-05-23 14:25:20 +0100 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2018-06-12 21:15:33 +0100 |
commit | 9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70 (patch) | |
tree | 282999f408198c09c80a61d12db0efe99ee3f46c /ld/Makefile.am | |
parent | defd21729f1ceb51999afcb342310835f8ab2faf (diff) | |
download | gdb-9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70.zip gdb-9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70.tar.gz gdb-9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70.tar.bz2 |
gdb: Mark async event handler when event is already pending
In PR22882 inferior functions are called on different threads while
scheduler-locking is turned on. This results in a hang. This was
discussed in this mailing list thread:
https://sourceware.org/ml/gdb/2017-10/msg00032.html
The problem is that when the thread is set running in order to execute
the inferior call, a call to target_async is made. If the target is
not already registered as 'target_async' then this will install the
async event handler, AND unconditionally mark the handler as having an
event pending.
However, if the target is already registered as target_async then the
event handler is not installed (its already installed) and the
handler is NOT marked as having an event pending.
If we try to set running a thread that already has a pending event,
then we do want to set target_async, however, there will not be an
external event incoming (the thread is already stopped) so we rely on
manually marking the event handler as having a pending event in order
to see the threads pending stop event. This is fine, if, at the point
where we call target_async, the target is not already marked as async.
But, if it is, then the event handler will not be marked as ready, and
the threads pending stop event will never be processed.
A similar pattern of code can be seen in linux_nat_target::resume,
where, when a thread has a pending event, the call to target_async is
followed by a call to async_file_mark to ensure that the pending
thread event will be processed, even if target_async was already set.
gdb/ChangeLog:
PR gdb/22882
* infrun.c (resume_1): Add call to mark_async_event_handler.
gdb/testsuite/ChangeLog:
* gdb.threads/multiple-successive-infcall.exp: Remove kfail case,
rewrite test to describe action performed, rather than possible
failure.
Diffstat (limited to 'ld/Makefile.am')
0 files changed, 0 insertions, 0 deletions