diff options
author | Joel Brobecker <brobecker@adacore.com> | 2019-04-30 16:00:19 -0500 |
---|---|---|
committer | Joel Brobecker <brobecker@adacore.com> | 2019-04-30 17:00:19 -0400 |
commit | ab4ee6147eb2e8fafd1fb96c945029c789182d3b (patch) | |
tree | 467cc690e1dc3c7e557145c272e84451606554fa /gdb/remote-fileio.h | |
parent | 8ed5b76ea2de370265382dab1d538a919e2603ab (diff) | |
download | binutils-ab4ee6147eb2e8fafd1fb96c945029c789182d3b.zip binutils-ab4ee6147eb2e8fafd1fb96c945029c789182d3b.tar.gz binutils-ab4ee6147eb2e8fafd1fb96c945029c789182d3b.tar.bz2 |
gdb/windows-nat.c: Get rid of main_thread_id global
This global is meant to point to the "main" thread of execution of
the program we are debugging. It is set when attaching to a process
or when receiving a CREATE_PROCESS_DEBUG_EVENT event. The theory at
the time was that this was also going to be the thread receiving
the EXIT_PROCESS_DEBUG_EVENT event.
Unfortunately, we have discovered since then that this is actually
not guaranteed. What this means in practice is that there is moderate
risk that main_thread_id refers to a thread which no longer exists.
This global is used in 3 situations:
- OUTPUT_DEBUG_STRING_EVENT
- LOAD_DLL_DEBUG_EVENT
- UNLOAD_DLL_DEBUG_EVENT
It's not clear why we would need to use the main_thread_id in those cases
instead of using the thread ID provided by the kernel events itself.
So this patch implements this approach, which then allows us to delete
the main_thread_id global.
gdb/testsuite:
* windows-nat.c (main_thread_id): Delete.
(handle_output_debug_string): Replace main_thread_id by
current_event.dwThreadId.
(fake_create_process): Likewise.
(get_windows_debug_event) <CREATE_PROCESS_DEBUG_EVENT>:
Do not set main_thread_id.
<LOAD_DLL_DEBUG_EVENT>: Replace main_thread_id by
current_event.dwThreadId.
<UNLOAD_DLL_DEBUG_EVENT>: Likewise.
Diffstat (limited to 'gdb/remote-fileio.h')
0 files changed, 0 insertions, 0 deletions