aboutsummaryrefslogtreecommitdiff
path: root/gdb/thread.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-08-10 14:41:30 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-09-08 10:47:27 +0100
commit351031f22adc77a63663cb2ac729864867d149c1 (patch)
tree938719a1e21f9b14ef29a031a2e9d296bf5ff37a /gdb/thread.c
parent42f46152849a2d4bd06a87c2dc795de1f7fc1af7 (diff)
downloadgdb-351031f22adc77a63663cb2ac729864867d149c1.zip
gdb-351031f22adc77a63663cb2ac729864867d149c1.tar.gz
gdb-351031f22adc77a63663cb2ac729864867d149c1.tar.bz2
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.
Diffstat (limited to 'gdb/thread.c')
-rw-r--r--gdb/thread.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/thread.c b/gdb/thread.c
index c95a918..10c3dcd 100644
--- a/gdb/thread.c
+++ b/gdb/thread.c
@@ -324,7 +324,7 @@ thread_info::set_executing (bool executing)
{
m_executing = executing;
if (executing)
- this->set_stop_pc (~(CORE_ADDR) 0);
+ this->clear_stop_pc ();
}
/* See gdbthread.h. */