[Bug remote/30129] New: Thread exited messages are missing for remote targets

[Bug remote/30129] New: Thread exited messages are missing for remote targets

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30129

            Bug ID: 30129
           Summary: Thread exited messages are missing for remote targets
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: aburgess at redhat dot com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/30129] Thread exited messages are missing for remote targets

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30129

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/30129] Thread exited messages are missing for remote targets

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30129

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/30129] Thread exited messages are missing for remote targets

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30129

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #3 from Andrew Burgess <aburgess at redhat dot com> ---
Issue should now be resolved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.