The remote target fails to print "[Thread ... exited]" messages in the CLI output. This can be seen as test failures in the test script gdb.threads/thread-specific-bp.exp. Here's the test binary being run on native: $ ./gdb/gdb -q -ex 'set sysroot /' --data-directory ./gdb/data-directory/ ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp Reading symbols from ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp... (gdb) b start Breakpoint 1 at 0x40113e: file /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c, line 23. (gdb) r Starting program: /tmp/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff7c5d700 (LWP 1234259)] [Switching to Thread 0x7ffff7c5d700 (LWP 1234259)] Thread 2 "thread-specific" hit Breakpoint 1, start (arg=0x0) at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:23 23 return NULL; (gdb) c Continuing. [Thread 0x7ffff7c5d700 (LWP 1234259) exited] [Inferior 1 (process 1234256) exited normally] (gdb) And here's the same session but using a remote target: $ ./gdb/gdb -q -ex 'set sysroot /' --data-directory ./gdb/data-directory/ ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp Reading symbols from ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp... (gdb) target extended-remote | gdbserver --once - ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp Remote debugging using | gdbserver --once - ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp stdin/stdout redirected Process ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp created; pid = 1234988 Remote debugging using stdio Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) b start Breakpoint 1 at 0x40113e: file /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c, line 23. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp stdin/stdout redirected Process ./gdb/testsuite/outputs/gdb.threads/thread-specific-bp/thread-specific-bp created; pid = 1235004 warning: while parsing target library list (at line 1): Required attribute "lmid" of <library> not specified [New Thread 1235004.1235005] [Switching to Thread 1235004.1235005] Thread 2 "thread-specific" hit Breakpoint 1, start (arg=0x0) at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:23 23 return NULL; (gdb) c Continuing. [Inferior 1 (process 1235004) exited normally] (gdb) Notice the '[Thread ... exited]' message is missing for the remote session. I posted a small patch to fix this issue here: https://sourceware.org/pipermail/gdb-patches/2022-November/194204.html However, this was rejected in favour of a bigger refactoring, which is unfortunately #30 in a 31 patch series: https://sourceware.org/pipermail/gdb-patches/2022-December/194694.html Until that's merged I need a bug-id that I can use in XFAIL messages for new tests that I'm adding.
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=89702edd933a5595557bcd9cc4a0dcc3262226d4 commit 89702edd933a5595557bcd9cc4a0dcc3262226d4 Author: Tom de Vries <tdevries@suse.de> Date: Thu Mar 9 12:31:26 2023 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver With test-case gdb.threads/thread-specific-bp.exp and target board native-gdbserver I run into: ... (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected continue^M Continuing.^M Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M ^M Thread 1 "thread-specific" hit Breakpoint 4, end () at \ thread-specific-bp.c:29^M 29 }^M (gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \ continue to end (timeout) ... The problem is that the test-case tries to match the "[Thread ... exited]" message which we do see with native testing: ... Continuing.^M [Thread 0x7ffff746e700 (LWP 7047) exited]^M Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M ... The fact that the message is missing was reported as PR remote/30129. We could add a KFAIL for this, but the functionality the test-case is trying to test has nothing to do with the message, so it should pass. I only added matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so broke testing on native-gdbserver. Fix this by matching the "Thread-specific breakpoint $decimal deleted" message instead. Tested on x86_64-linux.
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9d7d58e7262eff313be6a1e66b8b026e3e7fed0d commit 9d7d58e7262eff313be6a1e66b8b026e3e7fed0d Author: Pedro Alves <pedro@palves.net> Date: Mon Dec 12 20:31:00 2022 +0000 gdb: centralize "[Thread ...exited]" notifications Currently, each target backend is responsible for printing "[Thread ...exited]" before deleting a thread. This leads to unnecessary differences between targets, like e.g. with the remote target, we never print such messages, even though we do print "[New Thread ...]". E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we currently see: (gdb) c Continuing. ^C[New Thread 3850398.3887449] [New Thread 3850398.3887500] [New Thread 3850398.3887551] [New Thread 3850398.3887602] [New Thread 3850398.3887653] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) Above, we only see "New Thread" notifications, even though threads were deleted. After this patch, we'll see: (gdb) c Continuing. ^C[Thread 3558643.3577053 exited] [Thread 3558643.3577104 exited] [Thread 3558643.3577155 exited] [Thread 3558643.3579603 exited] ... [New Thread 3558643.3597415] [New Thread 3558643.3600015] [New Thread 3558643.3599965] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) q This commit fixes this by moving the thread exit printing to common code instead, triggered from within delete_thread (or rather, set_thread_exited). There's one wrinkle, though. While most targest want to print: [Thread ... exited] the Windows target wants to print: [Thread ... exited with code <exit_code>] ... and sometimes wants to suppress the notification for the main thread. To address that, this commits adds a delete_thread_with_code function, only used by that target (so far). This fix was originally posted as part of a larger series: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ But didn't really need to be part of that series. In order to get this fix merged sooner, I (Andrew Burgess) have rebased this commit outside of the original series. Any bugs introduced while splitting this patch out and rebasing, are entirely my own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Issue should now be resolved.