Instead of using a static buffer. This is safer, and we don't really
mind about any extra dynamic allocation here, since it's only used for
debug purposes.
gdb/ChangeLog:
* nat/linux-waitpid.c (status_to_str): Return std::string.
* nat/linux-waitpid.h (status_to_str): Likewise.
* linux-nat.c (linux_nat_post_attach_wait): Adjust.
(linux_nat_target::attach): Adjust.
(linux_handle_extended_wait): Adjust.
(wait_lwp): Adjust.
(stop_wait_callback): Adjust.
(linux_nat_filter_event): Adjust.
(linux_nat_wait_1): Adjust.
* nat/linux-waitpid.c (status_to_str): Adjust.
* nat/linux-waitpid.h (status_to_str): Adjust.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::wait_for_event_filtered):
Adjust to status_to_str returning std::string.
Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
Currently, in order to tell whether support for disabling address
space randomization on Linux is available, GDB checks if the
personality syscall works, at configure time. I.e., it does a run
test, instead of a compile/link test:
AC_RUN_IFELSE([PERSONALITY_TEST],
[have_personality=true],
[have_personality=false],
This is a bit bogus, because the machine the build is done on may not
(and is when you consider distro gdbs) be the machine that eventually
runs gdb. It would be better if this were a compile/link test
instead, and then at runtime, GDB coped with the personality syscall
failing. Actually, GDB already copes.
One environment where this is problematic is building GDB in a Docker
container -- by default, Docker runs the container with seccomp, with
a profile that disables the personality syscall. You can tell Docker
to use a less restricted seccomp profile, but I think we should just
fix it in GDB.
"man 2 personality" says:
This system call first appeared in Linux 1.1.20 (and thus first
in a stable kernel release with Linux 1.2.0); library support
was added in glibc 2.3.
...
ADDR_NO_RANDOMIZE (since Linux 2.6.12)
With this flag set, disable address-space-layout randomization.
glibc 2.3 was released in 2002.
Linux 2.6.12 was released in 2005.
The original patch that added the configure checks was submitted in
2008. The first version of the patch that was submitted to the list
called personality from common code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html
and then was moved to Linux-specific code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html
Since HAVE_PERSONALITY is only checked in Linux code, and
ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely
removing the configure checks.
If for some odd reason, some remotely modern system still needs a
configure check, then we can revert this commit but drop the
AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE
cross-compile fallback.
gdb/ChangeLog:
* linux-nat.c (linux_nat_target::supports_disable_randomization):
Remove references to HAVE_PERSONALITY.
* nat/linux-personality.c: Remove references to HAVE_PERSONALITY.
(maybe_disable_address_space_randomization)
(~maybe_disable_address_space_randomizatio): Remove references to
HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbserver/ChangeLog:
* linux-low.cc:
(linux_process_target::supports_disable_randomization): Remove
reference to HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbsupport/ChangeLog:
* common.m4 (personality test): Remove.
Lancelot pointed out that since the refactor at:
https://sourceware.org/pipermail/gdb-patches/2015-January/120503.html
the sys/personality.h include is not needed in linux-low.cc anymore,
as it does not call personality directly itself anymore.
gdbserver/ChangeLog:
* linux-low.cc: Don't include sys/personality.h or define
ADDR_NO_RANDOMIZE.
The 'handle_v_attach', 'handle_v_run', and 'handle_v_kill' functions'
return values are unused. They indicate error/success result by
putting packets. Make the functions void.
Tested by rebuilding.
gdbserver/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* server.cc (handle_v_attach)
(handle_v_run)
(handle_v_kill): Make void.
PR build/27807 points out that my recent changes to the Windows port
missed a spot in win32-i386-low.cc -- a call to
win32_Wow64GetThreadContext remained, causing link errors in
gdbserver. This happened because I tested an i686 build, but this
code is only used on an x86_64 build.
This patch fixes the bug. I am checking it in.
gdbserver/ChangeLog
2021-05-03 Tom Tromey <tromey@adacore.com>
PR build/27807:
* win32-i386-low.cc (i386_get_thread_context): Call
Wow64GetThreadContext, not win32_Wow64GetThreadContext.
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (do_initial_child_stuff): Update.
(windows_nat::handle_load_dll): Rename from win32_add_one_solib.
Change parameter type.
(win32_add_dll, win32_add_all_dlls)
(windows_nat::handle_load_dll): Remove.
(get_child_debug_event): Call dll_loaded_event.
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (GenerateConsoleCtrlEvent): New define.
(GenerateConsoleCtrlEvent_ftype, GenerateConsoleCtrlEvent):
Declare.
* nat/windows-nat.c (GenerateConsoleCtrlEvent): Define.
(initialize_loadable): Initialize GenerateConsoleCtrlEvent.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (GETPROCADDRESS): Remove.
(winapi_DebugActiveProcessStop, winapi_DebugSetProcessKillOnExit)
(winapi_DebugBreakProcess, winapi_GenerateConsoleCtrlEvent)
(winapi_Wow64SetThreadContext, win32_Wow64GetThreadContext)
(win32_Wow64SetThreadContext): Remove.
(win32_set_thread_context, do_initial_child_stuff)
(win32_process_target::attach, win32_process_target::detach):
Update.
(winapi_EnumProcessModules, winapi_EnumProcessModulesEx)
(winapi_GetModuleInformation, winapi_GetModuleInformationA):
Remove.
(win32_EnumProcessModules, win32_EnumProcessModulesEx)
(win32_GetModuleInformation, win32_GetModuleInformationA):
Remove.
(load_psapi): Remove.
(win32_add_dll, win32_process_target::request_interrupt): Update.
(initialize_low): Call initialize_loadable.
This removes the one last use of _WIN32_WCE from gdbserver.
gdbserver/ChangeLog
2021-04-14 Tom Tromey <tromey@adacore.com>
* win32-low.cc (windows_nat::handle_load_dll): Don't check
_WIN32_WCE.
I noticed that gdbserver/win32-low.cc has a few typedefs that are not
used. This patch removes them.
gdbserver/ChangeLog
2021-04-13 Tom Tromey <tromey@adacore.com>
* win32-low.cc (winapi_CreateToolhelp32Snapshot)
(winapi_Module32First, winapi_Module32Next): Remove typedefs.
The support for WinCE was removed with commit 84b300de36 ("gdbserver:
remove support for ARM/WinCE"). There is some leftover code for WinCE
support, guarded by the _WIN32_WCE macro, which I didn't know of at the
time.
I didn't remove the _WIN32_WCE references in the tests, because in
theory we still support the WinCE architecture in GDB (when debugging
remotely). So someone could run a test with that (although I'd be
really surprised).
gdb/ChangeLog:
* nat/windows-nat.c: Remove all code guarded by _WIN32_WCE.
* nat/windows-nat.h: Likewise.
gdbserver/ChangeLog:
* win32-low.cc: Remove all code guarded by _WIN32_WCE.
* win32-low.h: Likewise.
Change-Id: I7a871b897e2135dc195b10690bff2a01d9fac05a
This fixes win32-low.cc in the same way as a recent change in
windows-nat.c did for GDB: if the lpImageName member of the load-DLL
debug event doesn't allow us to find the file name of the DLL, then
loop over all the DLLs mapped into the inferior to find the one loaded
at the same base address as given by the lpBaseOfDll member of the
debug event.
gdbserver/ChangeLog:
2021-04-11 Eli Zaretskii <eliz@gnu.org>
* win32-low.cc (win32_add_dll): New function, with body almost
identical to what win32_add_all_dlls did. Accepts one argument;
if that is non-NULL, returns the file name of the DLL that is
loaded at the base address equal to that argument, or NULL if not
found. If the argument is NULL, add all the DLLs loaded by the
inferior to the list of solibs and return NULL.
(win32_add_all_dlls): Now a thin wrapper around win32_add_dll.
(windows_nat::handle_load_dll) [!_WIN32_WCE]: If get_image_name
failed to glean the file name of the DLL, call win32_add_dll to
try harder using the lpBaseOfDll member of the load-DLL event.
During reviews, I changed the success/failure variables from int to bool, but
missed updating the code in a couple spots. Given the logic inversion, the
gdbserver code fails instead of succeeding.
Fixed with the following patch. Seems fairly obvious, so I'll push it soon.
gdbserver/ChangeLog:
2021-03-30 Luis Machado <luis.machado@linaro.org>
* server.cc (handle_general_set, handle_query): Update variable
to bool and fix verification logic.
Adds the AArch64-specific memory tagging support (MTE) by implementing the
required hooks and checks for GDBserver.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (SFILES): Add /../gdb/nat/aarch64-mte-linux-ptrace.c.
* configure.srv (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o and
nat/aarch64-mte-linux-ptrace.o.
* linux-aarch64-low.cc: Include nat/aarch64-mte-linux-ptrace.h.
(class aarch64_target) <supports_memory_tagging>
<fetch_memtags, store_memtags>: New method overrides.
(aarch64_target::supports_memory_tagging)
(aarch64_target::fetch_memtags)
(aarch64_target::store_memtags): New methods.
AArch64 MTE support in the Linux kernel exposes a new register
through ptrace. This patch adds the required code to support it.
include/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* elf/common.h (NT_ARM_TAGGED_ADDR_CTRL): Define.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c (fetch_mteregs_from_thread): New function.
(store_mteregs_to_thread): New function.
(aarch64_linux_nat_target::fetch_registers): Update to call
fetch_mteregs_from_thread.
(aarch64_linux_nat_target::store_registers): Update to call
store_mteregs_to_thread.
* aarch64-tdep.c (aarch64_mte_register_names): New struct.
(aarch64_cannot_store_register): Handle MTE registers.
(aarch64_gdbarch_init): Initialize and setup MTE registers.
* aarch64-tdep.h (gdbarch_tdep) <mte_reg_base>: New field.
<has_mte>: New method.
* arch/aarch64-linux.h (AARCH64_LINUX_SIZEOF_MTE): Define.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (aarch64_fill_mteregset): New function.
(aarch64_store_mteregset): New function.
(aarch64_regsets): Add MTE register set entry.
(aarch64_sve_regsets): Add MTE register set entry.
This patch adds a target description and feature "mte" for aarch64.
It includes one new register, tag_ctl, that can be used to configure the
tag generation rules and sync/async modes. It is 64-bit in size.
The patch also adjusts the code that creates the target descriptions at
runtime based on CPU feature checks.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::read_description): Take MTE flag into
account.
Slight refactor to hwcap flag checking.
* aarch64-linux-tdep.c
(aarch64_linux_core_read_description): Likewise.
* aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for
MTE.
(aarch64_read_description): Add mte_p parameter and update to use it.
Update the documentation.
(aarch64_gdbarch_init): Update call to aarch64_read_description.
* aarch64-tdep.h (aarch64_read_description): Add mte_p parameter.
* arch/aarch64.c: Include ../features/aarch64-mte.c.
(aarch64_create_target_description): Add mte_p parameter and update
the code to use it.
* arch/aarch64.h (aarch64_create_target_description): Add mte_p
parameter.
* features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml.
* features/aarch64-mte.c: New file, generated.
* features/aarch64-mte.xml: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to
aarch64_linux_read_description.
(initialize_low_tracepoint): Likewise.
* linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag
into account.
* linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension
for MTE.
(aarch64_linux_read_description): Add mte_p parameter and update to
use it.
* linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p
parameter.
This patch is a preparation for the next patches implementing MTE. It just adds
a HWCAP2 constant for MTE, creates a new generic arch/aarch64-mte-linux.h file
and includes that file in the source files that will use it.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h.
* aarch64-linux-nat.c: Include arch/aarch64-mte-linux.h.
* aarch64-linux-tdep.c: Likewise
* arch/aarch64-mte-linux.h: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc: Include arch/aarch64-mte-linux.h.
Add some unit testing to exercise the functions handling the qMemTags and
QMemTags packets as well as feature support.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* server.cc (test_memory_tagging_functions): New function.
(captured_main): Register test_memory_tagging_functions.
This patch adds the generic remote bits to gdbserver so it can check for memory
tagging support and handle fetch tags and store tags requests.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* remote-utils.cc (decode_m_packet_params): Renamed from ...
(decode_m_packet): ... this, which now calls decode_m_packet_params.
Make char * param/return const char *.
(decode_M_packet): Use decode_m_packet_params and make char * param
const char *.
* remote-utils.h (decode_m_packet_params): New prototype.
(decode_m_packet): Constify char pointers.
(decode_M_packet): Likewise.
* server.cc (create_fetch_memtags_reply)
(parse_store_memtags_request): New
functions.
(handle_general_set): Handle the QMemTags packet.
(parse_fetch_memtags_request): New function.
(handle_query): Handle the qMemTags packet and advertise memory
tagging support.
(captured_main): Initialize memory tagging flag.
* server.h (struct client_state): Initialize memory tagging flag.
* target.cc (process_stratum_target::supports_memory_tagging)
(process_stratum_target::fetch_memtags)
(process_stratum_target::store_memtags): New methods.
* target.h: Include gdbsupport/byte-vector.h.
(class process_stratum_target) <supports_memory_tagging>
<fetch_memtags, store_memtags>: New class virtual methods.
(target_supports_memory_tagging): Define.
The 'all_dlls' list is global. This would cause the complete dll list
to be reported for individual processes. Move the list into the
process_info struct.
Currently the dll list is used only by the win32-low target, which
does not support the multi-process feature. Therefore, it practically
does not matter whether the list is global or per-process. However,
there may be targets that are outside the binutils-gdb repo (e.g. we,
at Intel, have such a target) that have multi-process and use the dll
list. So, it makes sense to do the right thing.
gdbserver/ChangeLog:
2021-03-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* inferiors.h (struct process_info) <all_dlls, dlls_changed>: New
fields.
* dll.h (loaded_dll)
(unloaded_dll): Declare an overloaded version that takes a proc
parameter.
* dll.cc (loaded_dll)
(unloaded_dll): Implement the overloaded versions.
(clear_dlls): Clear all process' dll lists.
(all_dlls, dlls_changed): Remove the global variables.
* remote-utils.cc (prepare_resume_reply): Update to consider a dll
list per proc.
* server.cc (handle_qxfer_libraries): Ditto.
(handle_v_attach): Ditto.
(captured_main): Ditto.
Same as the previous patch, but for GDBserver. The return value of this
method is never used, change it to return void.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::filter_event): Return
void.
* linux-low.h (class linux_process_target) <filter_event>:
Return void.
Change-Id: I79e5dc04d9b21b9f01c6d675fa463d1b1a703b3a
I've been using gdbreplay to help debug an intermittent failure, and I
wanted it to be a little simpler to use. This patch adds support for
"-" as the "address" argument. With this patch you can do:
(gdb) target remote | gdbreplay logfile -
... and not have to start gdbreplay in a separate shell.
2021-02-12 Tom Tromey <tromey@adacore.com>
* gdbreplay.cc (remote_desc): Remove.
(remote_desc_in, remote_desc_out): New globals.
(remote_close): Update.
(remote_open): Handle "-".
(remote_open): Update.
(logchar): Log to stderr.
(expect, play): Update.
This fixes PR27184, a failure to compile gdb due to
cdefs.h being out of sync with glibc on ppc64le targets
which are compiled with -mabi=ieeelongdouble and glibc
2.32.
Likewise, update usage of _GL_ATTRIBUTE_FORMAT_PRINTF to
_GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD.
Likewise, disable newly added rpl_free gnulib api in
gdbserver support libraries.
Likewise, undefine read/write macros before redefining them
on mingw targets.
Likewise, wrap C++ usage of free with GNULIB_NAMESPACE namespace
as needed.
Change-Id: I86517613c0d8ac8f5ea45bbc4ebe2b54a3aef29f
A following patch will add a new testcase that has two processes, each
with a number of threads constantly tripping a breakpoint and stepping
over it, because the breakpoint has a condition that evals false.
Then GDB detaches from one of the processes, while both processes are
running. And then the testcase sends a SIGUSR1 to the other process.
When run against gdbserver, that would occasionaly fail like this:
(gdb) PASS: gdb.threads/detach-step-over.exp: iter 1: detach
Executing on target: kill -SIGUSR1 208303 (timeout = 300)
spawn -ignore SIGHUP kill -SIGUSR1 208303
Thread 2.5 "detach-step-ove" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 208303.208305]
0x000055555555522a in thread_func (arg=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/detach-step-over.c:54
54 counter++; /* Set breakpoint here. */
What happened was that GDBserver is doing a step-over for process A
when a detach request for process B arrives. And that generates a
spurious SIGTRAP report for process A, as seen above.
The GDBserver logs reveal what happened:
- GDB manages to detach while a step over is in progress. That reaches
linux_process_target::complete_ongoing_step_over(), which does:
/* Passing NULL_PTID as filter indicates we want all events to
be left pending. Eventually this returns when there are no
unwaited-for children left. */
ret = wait_for_event_filtered (minus_one_ptid, null_ptid, &wstat,
__WALL);
As the comment say, this leaves all events pending, _including_ the
just finished step SIGTRAP. We never discard that SIGTRAP. So
GDBserver reports the SIGTRAP to GDB. GDB can't explain the
SIGTRAP, so it reports it to the user.
The GDBserver log looks like this. The LWP of interest is 208305:
Need step over [LWP 208305]? yes, found breakpoint at 0x555555555227
proceed_all_lwps: found thread 208305 needing a step-over
Starting step-over on LWP 208305. Stopping all threads
208305 starts a step-over.
>>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
stop_all_lwps (stop-and-suspend, except=LWP 208303.208305)
Sending sigstop to lwp 208303
Sending sigstop to lwp 207755
wait_for_sigstop: pulling events
LWFE: waitpid(-1, ...) returned 207755, ERRNO-OK
LLW: waitpid 207755 received Stopped (signal) (stopped)
pc is 0x7f7e045593bf
Expected stop.
LLW: SIGSTOP caught for LWP 207755.207755 while stopping threads.
LWFE: waitpid(-1, ...) returned 208303, ERRNO-OK
LLW: waitpid 208303 received Stopped (signal) (stopped)
pc is 0x7ffff7e743bf
Expected stop.
LLW: SIGSTOP caught for LWP 208303.208303 while stopping threads.
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
LLW: exit (no unwaited-for LWP)
stop_all_lwps done, setting stopping_threads back to !stopping
<<<< exiting void linux_process_target::stop_all_lwps(int, lwp_info*)
Done stopping all threads for step-over.
pc is 0x555555555227
Writing 8b to 0x555555555227 in process 208305
Could not findsigchld_handler
fast tracepoint jump at 0x555555555227 in list (uninserting).
pending reinsert at 0x555555555227
step from pc 0x555555555227
Resuming lwp 208305 (step, signal 0, stop expected)
<<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)
handling possible serial event
getpkt ("D;32b8b"); [no ack sent]
The detach request arrives.
sigchld_handler
Tracing is already off, ignoring
detach: step over in progress, finish it first
GDBserver realizes a step over for 208305 was in progress, let's it
finish.
LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
LLW: waitpid 208305 received Stopped (signal) (stopped)
pc is 0x555555555227
Expected stop.
LLW: step LWP 208303.208305, 0, 0 (discard delayed SIGSTOP)
pending reinsert at 0x555555555227
step from pc 0x555555555227
Resuming lwp 208305 (step, signal 0, stop not expected)
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
sigsuspend'ing
LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
LLW: waitpid 208305 received Trace/breakpoint trap (stopped)
pc is 0x55555555522a
CSBB: LWP 208303.208305 stopped by trace
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
LLW: exit (no unwaited-for LWP)
Finished step over.
The step-over for 208305 finishes.
Writing cc to 0x555555555227 in process 208305
Could not find fast tracepoint jump at 0x555555555227 in list (reinserting).
>>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
stop_all_lwps (stop, except=none)
wait_for_sigstop: pulling events
The detach proceeds (snipped).
...
proceed_one_lwp: lwp 208305
LWP 208305 has pending status, leaving stopped
Later on, 208305 has a pending status (the step SIGTRAP from the
step-over), so GDBserver starts the process of reporting it.
...
wait_1 ret = LWP 208303.208305, 1, 5
<<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)
...
and eventually GDB receives the stop notification (T05 == SIGTRAP):
getpkt ("vStopped"); [no ack sent]
sigchld_handler
vStopped: acking 3
Writing resume reply for LWP 208303.208305:1
putpkt ("$T0506:f0ee58f7ff7f0* ;07:f0ee58f7ff7f0* ;10:2a525*"550* ;thread:p32daf.32db1;core:c;#37"); [noack mode]
From the GDB side, we see:
[infrun] fetch_inferior_event: enter
[infrun] fetch_inferior_event: fetch_inferior_event enter
[infrun] do_target_wait: Found 2 inferiors, starting at #1
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 208303.208305.0 [Thread 208303.208305],
[infrun] print_target_wait_results: status->kind = stopped, signal = GDB_SIGNAL_TRAP
[infrun] handle_inferior_event: status->kind = stopped, signal = GDB_SIGNAL_TRAP
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 6
[infrun] operator(): putting back 6 threads to step in global queue
[infrun] start_step_over: exit
[infrun] handle_signal_stop: context switch
[infrun] context_switch: Switching context from process 0 to Thread 208303.208305
[infrun] handle_signal_stop: stop_pc=0x55555555522a
[infrun] handle_signal_stop: random signal (GDB_SIGNAL_TRAP)
[infrun] stop_waiting: stop_waiting
[infrun] stop_all_threads: starting
The fix is to discard the step SIGTRAP, unless GDB wanted the thread
to step.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::complete_ongoing_step_over):
Discard step SIGTRAP, unless GDB wanted the thread to step.
A following patch will add a testcase that has two processes with
threads stepping over a breakpoint continuously, and then detaches
from one of the processes while threads are running. The other
process continues stepping over its breakpoint. And then the testcase
sends a SIGUSR1, expecting that GDB reports it. That would sometimes
hang against gdbserver, due to the bugs fixed here. Both bugs are
related, in that they're about remote protocol asynchronous Stop
notifications. There's a bug in GDB, and another in GDBserver.
The GDB bug:
- when we detach from a process, the remote target discards any
pending RSP notification related to that process, including the
in-flight, yet-unacked notification. Discarding the in-flight
notification is the problem. Until the in-flight notification is
acked with a vStopped packet, the server won't send another %Stop
notification. As a result, the debug session gets messed up. In
the new testcase's case, GDB would hang inside stop_all_threads,
waiting for a stop for one of the process'es threads, which never
arrived -- its stop reply was permanently stuck in the stop reply
queue, waiting for a vStopped packet that never arrived.
In summary:
1. GDBserver sends stop notification about thread X, the remote
target receives it and stores it
2. At the same time, GDB detaches thread X's inferior
3. The remote target discards the received stop notification
4. GDBserver waits forever for the ack
The GDBserver bug:
GDBserver has the opposite bug. It also discards notifications for
the process being detached. If that discards the head of the
notification queue, when gdb sends an ack, it ends up acking the
_next_ notification. Meaning, gdb loses one notification. In the
testcase, this results in a similar hang in stop_all_threads.
So we have two very similar bugs in GDB and GDBserver, both resulting
in a similar symptom. That's why I'm fixing them both at the same
time.
gdb/ChangeLog:
* remote.c (remote_notif_stop_ack): Don't error out on
TARGET_WAITKIND_IGNORE; instead, just ignore the notification.
(remote_target::discard_pending_stop_replies): Don't delete
in-flight notification; instead, clear its contents.
gdbserver/ChangeLog:
* server.cc (discard_queued_stop_replies): Don't ever discard the
notification at the head of the list.
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...
When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...
The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS. After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.
Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.
The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f55 "Fix gdbserver qGetTLSAddr for
x86_64 -m32". The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument. But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.
Fix the segfault by redoing the fix from commit 9e0aa64f55 in minimal form.
Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
- native
- gdbserver -m32
- -m32
- openSUSE Factory (using kernel version 5.10.5):
- native
- m32
gdbserver/ChangeLog:
2021-01-20 Tom de Vries <tdevries@suse.de>
* linux-x86-low.cc (collect_register_i386): New function.
(x86_fill_gregset): Remove memset. Use collect_register_i386.
When doing a gdbserver build with CFLAGS/CXXFLAGS/LDFLAGS=-fsanitize=address
we run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o):
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
This started with commit 9664849417 "gdbsupport: make use of safe-ctype
functions from libiberty", which introduced a dependency of libinproctrace.so
on libiberty.
Fix this in gdbserver/Makefile.in by using a setup similar to what is done in
gcc-repo/src/libcc1/Makefile.am, such that ../libiberty/noasan/libiberty.a is
used instead.
Build on x86_64-linux, both with and without -fsanitize=address.
gdbserver/ChangeLog:
2021-01-07 Tom de Vries <tdevries@suse.de>
* Makefile.in (LIBIBERTY_NORMAL, LIBIBERTY_NOASAN, LIBIBERTY_PIC):
(LIBIBERTY_FOR_SHLIB): New var.
(LIBIBERTY): Set using $(LIBIBERTY_NORMAL).
(IPA_LIB): Use LIBIBERTY_FOR_SHLIB instead of LIBIBERTY in target rule.
I spent a lot of time reading infrun debug logs recently, and I think
they could be made much more readable by being indented, to clearly see
what operation is done as part of what other operation. In the current
format, there are no visual cues to tell where things start and end,
it's just a big flat list. It's also difficult to understand what
caused a given operation (e.g. a call to resume_1) to be done.
To help with this, I propose to add the new scoped_debug_start_end
structure, along with a bunch of macros to make it convenient to use.
The idea of scoped_debug_start_end is simply to print a start and end
message at construction and destruction. It also increments/decrements
a depth counter in order to make debug statements printed during this
range use some indentation. Some care is taken to handle the fact that
debug can be turned on or off in the middle of such a range. For
example, a "set debug foo 1" command in a breakpoint command, or a
superior GDB manually changing the debug_foo variable.
Two macros are added in gdbsupport/common-debug.h, which are helpers to
define module-specific macros:
- scoped_debug_start_end: takes a message that is printed both at
construction / destruction, with "start: " and "end: " prefixes.
- scoped_debug_enter_exit: prints hard-coded "enter" and "exit"
messages, to denote the entry and exit of a function.
I added some examples in the infrun module to give an idea of how it can
be used and what the result looks like. The macros are in capital
letters (INFRUN_SCOPED_DEBUG_START_END and
INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but
that can be changed if you prefer something else.
Here's an excerpt of the debug
statements printed when doing "continue", where a displaced step is
started:
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 1
[infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd
[displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now
[displaced] prepare: selected buffer at 0x5555555550c2
[displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83
[displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2
[displaced] resume_1: run 0x5555555550c2: c7 45 fc 00
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed.
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296)
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300)
[infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed
[infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302)
[infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: exit
We can easily see where the call to `proceed` starts and end. We can
also see why there are a bunch of resume_1 calls, it's because we are
resuming threads, emulating all-stop on top of a non-stop target.
We also see that debug statements nest well with other modules that have
been migrated to use the "new" debug statement helpers (because they all
use debug_prefixed_vprintf in the end. I think this is desirable, for
example we could see the debug statements about reading the DWARF info
of a library nested under the debug statements about loading that
library.
Of course, modules that haven't been migrated to use the "new" helpers
will still print without indentations. This will be one good reason to
migrate them.
I think the runtime cost (when debug statements are disabled) of this is
reasonable, given the improvement in readability. There is the cost of
the conditionals (like standard debug statements), one more condition
(if (m_must_decrement_print_depth)) and the cost of constructing a stack
object, which means copying a fews pointers.
Adding the print in fetch_inferior_event breaks some tests that use "set
debug infrun", because it prints a debug statement after the prompt. I
adapted these tests to cope with it, by using the "-prompt" switch of
gdb_test_multiple to as if this debug statement is part of the expected
prompt. It's unfortunate that we have to do this, but I think the debug
print is useful, and I don't want a few tests to get in the way of
adding good debug output.
gdbsupport/ChangeLog:
* common-debug.h (debug_print_depth): New.
(struct scoped_debug_start_end): New.
(scoped_debug_start_end): New.
(scoped_debug_enter_exit): New.
* common-debug.cc (debug_prefixed_vprintf): Print indentation.
gdb/ChangeLog:
* debug.c (debug_print_depth): New.
* infrun.h (INFRUN_SCOPED_DEBUG_START_END): New.
(INFRUN_SCOPED_DEBUG_ENTER_EXIT): New.
* infrun.c (start_step_over): Use
INFRUN_SCOPED_DEBUG_ENTER_EXIT.
(proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and
INFRUN_SCOPED_DEBUG_START_END.
(fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT.
gdbserver/ChangeLog:
* debug.cc (debug_print_depth): New.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect infrun debug print after
prompt.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/watchthreads-reorder.exp: Likewise.
Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
When inserting hw watchpoints, we take care of masking off the top byte
of the address (and sign-extending it if needed). This guarantees we won't
pass tagged addresses to the kernel via ptrace.
However, from the kernel documentation on tagged pointers...
"Non-zero tags are not preserved when delivering signals. This means that
signal handlers in applications making use of tags cannot rely on the tag
information for user virtual addresses being maintained for fields inside
siginfo_t.
One exception to this rule is for signals raised in response to watchpoint
debug exceptions, where the tag information will be preserved."
So the stopped data address after a hw watchpoint hit can be potentially
tagged, and we don't handle this in GDB at the moment. This results in
GDB missing a hw watchpoint hit and attempting to step over an unsteppable
hw watchpoint, causing it to spin endlessly.
The following patch fixes this by adjusting the stopped data address and adds
some tests to expose the problem.
gdb/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::stopped_data_address): Handle the TBI.
gdbserver/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (address_significant): New function.
(aarch64_target::low_stopped_data_address): Handle the TBI.
gdb/testsuite/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-tagged-pointer.c (main): Add a few more
pointer-based memory accesses.
* gdb.arch/aarch64-tagged-pointer.exp: Exercise additional
hw watchpoint cases.
Make use of the safe-ctype replacements for the standard ctype
character checking functions in gdbsupport/common-utils.cc. The
gdbsupport library is included into both gdb and gdbserver, and on the
gdbserver side there are two targets, gdbserver itself, and also
libinproctrace.so.
libiberty was already being included in the gdbserver link command,
but was missing from the libinproctrace.so link. As a result, after
changing gdbsupport/common-utils.cc to depend on libiberty,
libinproctrace.so would no longer link until I modified its link line.
gdbserver/ChangeLog:
* Makefile.in (IPA_LIB): Include libiberty library.
gdbsupport/ChangeLog:
* gdbsupport/common-utils.cc: Change 'ctype.h' include to
'safe-ctype.h'.
(extract_string_maybe_quoted): Use safe-ctype function versions.
(is_digit_in_base): Likewise.
(digit_to_int): Likewise.
(strtoulst): Likewise.
(skip_spaces): Likewise.
(skip_to_space): Likewise.
The help text for the --disable-packet option was missing one of the
possible values.
As this option is for maintainers only it is explicitly not documented
in gdb/doc/gdb.texinfo, so no update is needed there.
gdbserver/ChangeLog:
* server.cc (gdbserver_usage): Add missing option to usage text.
(gdbserver_show_disableable): Likewise.
... with AC_COMPILE_IFELSE and AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant
whitespace changes.
gdbserver/ChangeLog:
* acinclude.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE +
AC_LANG_PROGRAM.
* configure: Re-generate.
Change-Id: Idab8b5e1a984046b5283940c02e5a22da2291d58
For some reason, autoupdate isn't able to grok ptrace.m4:
$ autoupdate ptrace.m4
/usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string
autoupdate: /usr/bin/m4 failed with exit status: 1
Honestly, I'm unable to grok it either. This patch re-indents it in a
way that I think is easier to read. With this patch applied, autoupdate
becomes able to parse ptrace.m4, but I chose to keep this re-indent in a
patch of its own.
All the changes in generated configure files consist of insignificant
whitespace changes.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* ptrace.m4: Re-indent.
Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
Run autoupdate on gdbserver/configure.ac and then tweak it to use easier
to read indentation. This removes a few warnings when running
`autoreconf -vf -Wall`.
* Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR.
* Replace AC_GNU_SOURCE with AC_USE_SYSTEM_EXTENSIONS.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
autoupdate gets it right, except this one here:
--- a/gdbserver/configure.ac
+++ b/gdbserver/configure.ac
@@ -304,7 +304,7 @@ if test "$srv_linux_thread_db" = "yes"; then
AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[found="-Wl,--dynamic-list"
RDYNAMIC='-Wl,--dynamic-list=$(srcdir)/proc-service.list'],[RDYNAMIC="-rdynamic"
LDFLAGS="$old_LDFLAGS $RDYNAMIC"
- AC_TRY_LINK([], [],
+ _au_m4_changequote([,])AC_TRY_LINK([], [],
[found="-rdynamic"],
[found="no"
RDYNAMIC=""])])
... which I had to convert manually.
The changes in the generated configure file only contain insignificant
whitespace changes, so that gives confidence that the conversion is
correct.
gdbserver/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ia769aaec2aafac595504f477da955e91dffa4d8f
`autoreconf -Wall` notes that AC_CANONICAL_SYSTEM is obsolete:
configure.ac:36: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
Replace it by AC_CANONICAL_BUILD, AC_CANONICAL_HOST and
AC_CANONICAL_TARGET in configure.ac files in gdb, gdbserver and
gdbsupport. All three macros may not be needed everywhere, but it is
hard to completely audit the configure files to see which are required,
so I think it's better (and that there's no downside) to just call all
three.
gdb/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
Change-Id: Ifd0e21f1e478634e768b5de1b8ee06a7f690d863
This eliminates the need to specify the return type when using
handle_eintr. We let the compiler deduce it for us.
Also, use lowercase for function parameter names. Uppercase should
only be used on template parameters.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include "gdbsupport/eintr.h".
(my_waitpid): Use gdb::handle_eintr.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_waitpid, netbsd_process_target::kill)
(netbsd_qxfer_libraries_svr4): Use gdb::handle_eintr without
explicit type.
gdbsupport/ChangeLog:
* eintr.h (handle_eintr): Replace Ret template parameter with
ErrorValType. Use it as type of the failure value. Deduce the
function's return type using decltype. Use lowercase for function
parameter names.
ptrace.m4, providing the GDB_AC_PTRACE autoconf macro, is used by gdb,
gdbserver and gdbsupport. I think it would make sense to move it to
gdbsupport.
gdb/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Moved to gdbsupport.
gdbserver/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
gdbsupport/ChangeLog:
* Makefile.in: Re-generate.
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Move here.
Change-Id: I849c149fd5dd8c3b2b0af38654fb353e3727871b
I get this diff when I re-generate the configure script in gdbserver,
probably leftovers from e911c6663b ("Require kinfo_get_file and
kinfo_get_vmmap for FreeBSD hosts").
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
Change-Id: Id19a72ea9f3e7c7b4fdb0f319c9c0bbad0e39aeb
While trying to build on Cygwin (gcc 10.2.0), I got:
CXX server.o
/home/Baube/src/binutils-gdb/gdbserver/server.cc: In function 'void handle_general_set(char*)':
/home/Baube/src/binutils-gdb/gdbserver/server.cc:832:12: error: 'sprintf' argument 3 overlaps destination object 'own_buf' [-Werror=restrict]
832 | sprintf (own_buf, "E.Unknown thread-events mode requested: %s\n",
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
833 | mode);
| ~~~~~
/home/Baube/src/binutils-gdb/gdbserver/server.cc:553:27: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
553 | handle_general_set (char *own_buf)
| ~~~~~~^~~~~~~
There is indeed a problem: mode points somewhere into own_buf. And by
the time mode gets formatted as a %s, whatever it points to has been
overwritten. I hacked gdbserver to coerce it into that error path, and
this is the resulting message:
(gdb) p own_buf
$1 = 0x629000000200 "E.Unknown thread-events mode requested: ad-events mode requested: 00;10:9020fdf7ff7f0000;thread:p49388.49388;core:e;\n"
Fix it by formatting the error string in an std::string first.
gdbserver/ChangeLog:
* server.cc (handle_general_set): Don't use sprintf with
argument overlapping buffer.
Change-Id: I4fdf05c0117f63739413dd67ddae7bd6ee414824
PR gdb/26742 points out some undefined behavior in gdbserver. The bug
is that remove_thread does:
free_one_thread (thread);
if (current_thread == thread)
current_thread = NULL;
However, the equality check is undefined, because "thread" has already
been freed.
This patch fixes the bug by moving the check earlier.
Tested on x86-64 Fedora 32.
2020-10-20 Tom Tromey <tromey@adacore.com>
PR gdb/26742:
* inferiors.cc (remove_thread): Clear current_thread before
freeing the thread.
