[Bug threads/13042] New: Switching to thread after step/next doesn't mention old thread

[Bug threads/13042] New: Switching to thread after step/next doesn't mention old thread

[pfee at talk21 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13042

           Summary: Switching to thread after step/next doesn't mention
                    old thread
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
        AssignedTo: unassigned@sourceware.org
        ReportedBy: pfee@talk21.com


Created attachment 5868
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5868
Modify "Switching to <thread>" information to include old thread

During interactive debugging (all-stop rather than non-stop mode), issuing
step/next will resume all threads in the debugged process.  If a breakpoint is
hit in a different thread, then GDB outputs details of the new thread.

The user may wish to continue debugging the old thread, but without making note
of that thread before the step/next command, it's difficult to determine what
the previous thread was.

It would be good to enhance the output to include details of the old thread in
addition to the new thread.

I've attached a patch against infrun.c r1.497 (trunk) that implements this
enhancement.

The current GDB 7.3 output is:

============
(gdb) next
[New Thread 0x7ffff7fd6700 (LWP 4267)]
15        thr1.join();
(gdb) next
[Switching to Thread 0x7ffff7fd6700 (LWP 4267)]

Breakpoint 1, thread1 () at thread.cpp:9
9               cout << "Thread 1" << endl;
(gdb) info thread
  Id   Target Id         Frame 
* 2    Thread 0x7ffff7fd6700 (LWP 4267) "a.out" thread1 () at thread.cpp:9
  1    Thread 0x7ffff7fd8740 (LWP 4264) "a.out" pthread_cond_wait@@GLIBC_2.3.2
()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
============


Use the patch changes the output to:

============
(gdb) next
[New Thread 0x7ffff7fd6700 (LWP 4282)]
15        thr1.join();
(gdb) next
[Switching from Thread 0x7ffff7fd8740 (LWP 4279) to Thread 0x7ffff7fd6700 (LWP
4282)]

Breakpoint 1, thread1 () at thread.cpp:9
9               cout << "Thread 1" << endl;
(gdb) info thread
  Id   Target Id         Frame 
* 2    Thread 0x7ffff7fd6700 (LWP 4282) "a.out" thread1 () at thread.cpp:9
  1    Thread 0x7ffff7fd8740 (LWP 4279) "a.out" 0x0000003c1140b475 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
============

The patch uses strdup() to copy the results of the first target_pid_to_str()
call.  This is because target_pid_to_str() returns a pointer to a static buffer
which is reused in subsequent calls, hence I couldn't call target_pid_to_str()
twice to populate the two %s tokens in the printf_filtered() call.

I also considered making two printf_filtered() calls, each with one
target_pid_to_str() call, but felt that may introduce side effects depending on
how output gets buffered.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug threads/13042] Switching to thread after step/next doesn't mention old thread

[pfee at talk21 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13042

Paul Fee <pfee at talk21 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |pfee at talk21 dot com
                   |dot org                     |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.