diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-03-11 12:30:13 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-03-19 11:16:53 +0000 |
commit | cada5fc921e39a1945c422eea055c8b326d8d353 (patch) | |
tree | 99e4d731b9a132f96adfad10705760e6ee20e01c /gold/ffsll.c | |
parent | 6b8c53f2f1c0cf5bee46120d892d4c72571375eb (diff) | |
download | gdb-cada5fc921e39a1945c422eea055c8b326d8d353.zip gdb-cada5fc921e39a1945c422eea055c8b326d8d353.tar.gz gdb-cada5fc921e39a1945c422eea055c8b326d8d353.tar.bz2 |
gdb: Handle W and X remote packets without giving a warning
In this commit:
commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
Diffstat (limited to 'gold/ffsll.c')
0 files changed, 0 insertions, 0 deletions