improved thread id reporting

improved thread id reporting

[Doug Evans]

Hi.

GDB's current reporting of thread ids has (at least) three problems (IMO):
1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio.
2) When switching to a thread IWBN to also report the thread being switched
   from, otherwise one has to scrollback through the session to find it
   (assuming that's even possible).
3) When reporting thread ids the only usable number in the gdb session
   (gdb's internal thread number) is not included.

To fix (1) I'd like to simply remove the pthread id from the output.
This would be user selectable of course, and for example when using
MI I'd expect that it shouldn't be changed lest the frontend
get confused, but friendly reporting of thread ids in frontends
is the frontend's job anyway.

To fix (2) I propose to change "Switch to Thread ..." to
"Switching to Thread ... from Thread ...".

To fix (3) I propose to include gdb's thread number in
"[New Thread ...]" and "[Switching to Thread ...]" messages.

Actually implementing this may be a challenge
but I think the improvement is usability for the user warrants it.
[E.g. This change shouldn't affect non-threaded targets (e.g. embedded).]

Comments?

Example:

Before:

gdb$ ./gdb.prev -nx testsuite/gdb.threads/interrupted-hand-call 
GNU gdb (GDB) 6.8.50.20090404-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) b thread_entry
Breakpoint 1 at 0x8048319: file ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c, line 77.
(gdb) r
Starting program: /usr/local/g3/gnu/sourceware/thread-id/build/obj32/gdb/testsuite/gdb.threads/interrupted-hand-call 
[Thread debugging using libthread_db enabled]
[New Thread 0xf7e5cbb0 (LWP 17858)]
[Switching to Thread 0xf7e5cbb0 (LWP 17858)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77	  incr_thread_count ();
(gdb) c
Continuing.
[New Thread 0xf765bbb0 (LWP 17859)]
[Switching to Thread 0xf765bbb0 (LWP 17859)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77	  incr_thread_count ();
(gdb) i thr
[New Thread 0xf6e5abb0 (LWP 17862)]
  4 Thread 0xf6e5abb0 (LWP 17862)  0xf7f27748 in clone ()
   from /usr/grte/v1/lib/libc.so.6
* 3 Thread 0xf765bbb0 (LWP 17859)  thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
  2 Thread 0xf7e5cbb0 (LWP 17858)  0xffffe410 in __kernel_vsyscall ()
  1 Thread 0xf7e5d6b0 (LWP 17855)  0xf7f27748 in clone ()
   from /usr/grte/v1/lib/libc.so.6
(gdb) 



After:
[slightly different due to different o/s scheduling of threads, but
you get the idea]

gdb$ ./gdb -nx testsuite/gdb.threads/interrupted-hand-call 
GNU gdb (GDB) 6.8.50.20090404-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) b thread_entry
Breakpoint 1 at 0x8048319: file ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c, line 77.
(gdb) r
Starting program: /usr/local/g3/gnu/sourceware/thread-id/build/obj32/gdb/testsuite/gdb.threads/interrupted-hand-call 
[Thread debugging using libthread_db enabled]
[New Thread #2, LWP 17626]
[New Thread #3, LWP 17627]
[Switching to Thread #2, LWP 17626 from Thread #1, LWP 17626]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77	  incr_thread_count ();
(gdb) c
Continuing.
[Switching to Thread #3, LWP 17627 from Thread #2, LWP 17627]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77	  incr_thread_count ();
(gdb) i thr
[New Thread #4, LWP 17628]
  4 LWP 17628  0xffffe410 in __kernel_vsyscall ()
* 3 LWP 17627  thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
  2 LWP 17626  0xffffe410 in __kernel_vsyscall ()
  1 LWP 17623  0xf7fb9730 in __nptl_create_event ()
   from /usr/grte/v1/lib/libpthread.so.0
(gdb) 

Re: improved thread id reporting

[Mark Kettenis]

> Date: Sat,  4 Apr 2009 11:46:04 -0700 (PDT)
> From: dje@google.com (Doug Evans)
> 
> Hi.
> 
> GDB's current reporting of thread ids has (at least) three problems (IMO):
> 1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio.

Uh?  I'd say it has a very high S/N ratio; it's the only thing that
you can actually use to identify a thread to a particular thread
created by the code you're debugging.

Also realize that whatever is printed now between () is OS-specific
information that varies from OS to OS and may even be completely
absent in the case of user-level threads libraries.

> 2) When switching to a thread IWBN to also report the thread being switched
>    from, otherwise one has to scrollback through the session to find it
>    (assuming that's even possible).

That's not an unreasonable suggestion.

> 3) When reporting thread ids the only usable number in the gdb session
>    (gdb's internal thread number) is not included.

I don't consider this to be a big issue.  If I need a GDB internal
thread number, I find it no problem to just use the "info threads"
command and make decisions based on that.  I'd expect that to be much
more convenient than scrollback through the session ;)

That said, if it's possible to print them without creating additional
line breaks on an 80-column wide screen, I have no objections.

> To fix (1) I'd like to simply remove the pthread id from the output.

I think that's a bad idea.

Re: improved thread id reporting

[Thiago Jung Bauermann]

El sáb, 04-04-2009 a las 11:46 -0700, Doug Evans escribió:
> Comments?

I like it.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: improved thread id reporting

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: gdb@sourceware.org
> Date: Sat, 04 Apr 2009 16:07:45 -0300
> 
> El sáb, 04-04-2009 a las 11:46 -0700, Doug Evans escribió:
> > Comments?
> 
> I like it.

So do I.

Re: improved thread id reporting

[Daniel Jacobowitz]

On Sat, Apr 04, 2009 at 09:04:30PM +0200, Mark Kettenis wrote:
> > Date: Sat,  4 Apr 2009 11:46:04 -0700 (PDT)
> > From: dje@google.com (Doug Evans)
> > 
> > Hi.
> > 
> > GDB's current reporting of thread ids has (at least) three problems (IMO):
> > 1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio.
> 
> Uh?  I'd say it has a very high S/N ratio; it's the only thing that
> you can actually use to identify a thread to a particular thread
> created by the code you're debugging.
> 
> Also realize that whatever is printed now between () is OS-specific
> information that varies from OS to OS and may even be completely
> absent in the case of user-level threads libraries.

I agree with Mark.  I think the existing IDs are quite handy.

> > 2) When switching to a thread IWBN to also report the thread being switched
> >    from, otherwise one has to scrollback through the session to find it
> >    (assuming that's even possible).
> 
> That's not an unreasonable suggestion.

Agreed, although I'm curious what people think of "to X from Y" vs
"from Y to X" - I found your sample visually confusing.

> > 3) When reporting thread ids the only usable number in the gdb session
> >    (gdb's internal thread number) is not included.
> 
> I don't consider this to be a big issue.  If I need a GDB internal
> thread number, I find it no problem to just use the "info threads"
> command and make decisions based on that.  I'd expect that to be much
> more convenient than scrollback through the session ;)
> 
> That said, if it's possible to print them without creating additional
> line breaks on an 80-column wide screen, I have no objections.

I'd find these helpful.

-- 
Daniel Jacobowitz
CodeSourcery

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sat, 4 Apr 2009 15:21:32 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: dje@google.com, gdb@sourceware.org
> 
> I think the existing IDs are quite handy.

What for?  If they are useful, we should probably tell in the manual
how to use them.

> Agreed, although I'm curious what people think of "to X from Y" vs
> "from Y to X" - I found your sample visually confusing.

Indeed, "from Y to X" is a more natural order, IMO.

Re: improved thread id reporting

[Daniel Jacobowitz]

On Sat, Apr 04, 2009 at 11:37:53PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Apr 2009 15:21:32 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: dje@google.com, gdb@sourceware.org
> > 
> > I think the existing IDs are quite handy.
> 
> What for?  If they are useful, we should probably tell in the manual
> how to use them.

Their meaning is platform-specific; they're usually something that
will be recognized by programmers familiar with the OS in question.
On native Linux, they're the same as pthread_self would return.
I think they're just LWP IDs when using gdbserver; we had trouble
passing NPTL thread IDs over the remote protocol.

-- 
Daniel Jacobowitz
CodeSourcery

Re: improved thread id reporting

[Doug Evans]

On Sat, Apr 4, 2009 at 12:04 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Sat,  4 Apr 2009 11:46:04 -0700 (PDT)
>> From: dje@google.com (Doug Evans)
>>
>> Hi.
>>
>> GDB's current reporting of thread ids has (at least) three problems (IMO):
>> 1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio.
>
> Uh?  I'd say it has a very high S/N ratio; it's the only thing that
> you can actually use to identify a thread to a particular thread
> created by the code you're debugging.

Ok, "very low" is subjective and context dependent.

> Also realize that whatever is printed now between () is OS-specific
> information that varies from OS to OS and may even be completely
> absent in the case of user-level threads libraries.

Realized.

>> 2) When switching to a thread IWBN to also report the thread being switched
>>    from, otherwise one has to scrollback through the session to find it
>>    (assuming that's even possible).
>
> That's not an unreasonable suggestion.
>
>> 3) When reporting thread ids the only usable number in the gdb session
>>    (gdb's internal thread number) is not included.
>
> I don't consider this to be a big issue.  If I need a GDB internal
> thread number, I find it no problem to just use the "info threads"
> command and make decisions based on that.  I'd expect that to be much
> more convenient than scrollback through the session ;)

I've sometimes had to manually search the output of "info threads" and
map from pthread-id/lwp to gdb number when the source of the
pthread-id/lwp was the "[New ...]" or "[Switching ...]" message.
Blech.

> That said, if it's possible to print them without creating additional
> line breaks on an 80-column wide screen, I have no objections.
>
>> To fix (1) I'd like to simply remove the pthread id from the output.
>
> I think that's a bad idea.

Even as a user-settable option?

Re: improved thread id reporting

[Doug Evans]

On Sat, Apr 4, 2009 at 12:21 PM, Daniel Jacobowitz <drow@false.org> wrote:
>> > 2) When switching to a thread IWBN to also report the thread being switched
>> >    from, otherwise one has to scrollback through the session to find it
>> >    (assuming that's even possible).
>>
>> That's not an unreasonable suggestion.
>
> Agreed, although I'm curious what people think of "to X from Y" vs
> "from Y to X" - I found your sample visually confusing.

I like from/to better than to/from - I only picked to/from because it
seemed like less of a change (however minor) over the existing text
(YMMV).

Re: improved thread id reporting

[Doug Evans]

On Sat, Apr 4, 2009 at 2:21 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Apr 04, 2009 at 11:37:53PM +0300, Eli Zaretskii wrote:
>> > Date: Sat, 4 Apr 2009 15:21:32 -0400
>> > From: Daniel Jacobowitz <drow@false.org>
>> > Cc: dje@google.com, gdb@sourceware.org
>> >
>> > I think the existing IDs are quite handy.
>>
>> What for?  If they are useful, we should probably tell in the manual
>> how to use them.
>
> Their meaning is platform-specific; they're usually something that
> will be recognized by programmers familiar with the OS in question.
> On native Linux, they're the same as pthread_self would return.
> I think they're just LWP IDs when using gdbserver; we had trouble
> passing NPTL thread IDs over the remote protocol.

I checked gdbserver on linux.

(gdb) i thr
[New Thread 30119.30125]
  5 Thread 30119.30125  0xf7f27748 in clone () from /usr/lib/libc.so.6
* 4 Thread 30119.30124  thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
  3 Thread 30119.30121  incr_thread_count ()
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:44
  2 Thread 30119.30120  0xf7fbedbc in __pthread_enable_asynccancel ()
   from /usr/lib/libpthread.so.0
  1 Thread 30119.30119  0xf7f27748 in clone () from /usr/lib/libc.so.6

Kinda nice.

Re: improved thread id reporting

[Daniel Jacobowitz]

On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote:
> > That said, if it's possible to print them without creating additional
> > line breaks on an 80-column wide screen, I have no objections.
> >
> >> To fix (1) I'd like to simply remove the pthread id from the output.
> >
> > I think that's a bad idea.
> 
> Even as a user-settable option?

IMO, yes.  I don't think we need more settable options for details of
output formatting; 98% or so of users will use the default, so that's
the part that matters.

-- 
Daniel Jacobowitz
CodeSourcery

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sat, 4 Apr 2009 17:21:14 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: mark.kettenis@xs4all.nl, dje@google.com, gdb@sourceware.org
> 
> On native Linux, they're the same as pthread_self would return.

And how's that useful?

Re: improved thread id reporting

[Daniel Jacobowitz]

On Sun, Apr 05, 2009 at 06:11:10AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Apr 2009 17:21:14 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: mark.kettenis@xs4all.nl, dje@google.com, gdb@sourceware.org
> > 
> > On native Linux, they're the same as pthread_self would return.
> 
> And how's that useful?

You can use it to figure out which thread a pthread_t variable refers
to, since those are the same as returned by pthread_self.  Just look
it up in the list of threads.

-- 
Daniel Jacobowitz
CodeSourcery

Re: improved thread id reporting

[Paul Pluzhnikov]

On Sat, Apr 4, 2009 at 8:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 4 Apr 2009 17:21:14 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: mark.kettenis@xs4all.nl, dje@google.com, gdb@sourceware.org
>>
>> On native Linux, they're the same as pthread_self would return.
>
> And how's that useful?

Sometimes that's very useful.

One example is where thread has performed some logging with
its pthread_self, and you are now trying to figure out which
thread that was.

Another is when you are debugging a deadlock, and want to know
who is waiting on the given lock (thread ids of waiters are
stored somewhere in mutex_t, IIRC).

-- 
Paul Pluzhnikov

Re: improved thread id reporting

[Mark Kettenis]

> Date: Sat, 4 Apr 2009 21:11:34 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote:
> > > That said, if it's possible to print them without creating additional
> > > line breaks on an 80-column wide screen, I have no objections.
> > >
> > >> To fix (1) I'd like to simply remove the pthread id from the output.
> > >
> > > I think that's a bad idea.
> > 
> > Even as a user-settable option?
> 
> IMO, yes.  I don't think we need more settable options for details of
> output formatting; 98% or so of users will use the default, so that's
> the part that matters.

Seconded.

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sun, 5 Apr 2009 09:19:34 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: dje@google.com, gdb@sourceware.org
> 
> > Date: Sat, 4 Apr 2009 21:11:34 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote:
> > > > That said, if it's possible to print them without creating additional
> > > > line breaks on an 80-column wide screen, I have no objections.
> > > >
> > > >> To fix (1) I'd like to simply remove the pthread id from the output.
> > > >
> > > > I think that's a bad idea.
> > > 
> > > Even as a user-settable option?
> > 
> > IMO, yes.  I don't think we need more settable options for details of
> > output formatting; 98% or so of users will use the default, so that's
> > the part that matters.
> 
> Seconded.

Then we appear to have a draw, because I happen to agree with Doug.

And I really don't understand the argument against a user option: it
wasn't suggested as a means to get what, according to Daniel and Mark,
the majority of users need; it was suggested as a means for Doug (and
other minorities) to get what they want.  An option that is used in
rare situations by people with unconventional requests can hardly do
any real harm, because if Daniel and Mark are right, no one except
Doug will ever miss it or even know it exists.

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sat, 4 Apr 2009 20:47:56 -0700
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
> Cc: Daniel Jacobowitz <drow@false.org>, mark.kettenis@xs4all.nl,
>         dje@google.com, gdb@sourceware.org
> 
> On Sat, Apr 4, 2009 at 8:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sat, 4 Apr 2009 17:21:14 -0400
> >> From: Daniel Jacobowitz <drow@false.org>
> >> Cc: mark.kettenis@xs4all.nl, dje@google.com, gdb@sourceware.org
> >>
> >> On native Linux, they're the same as pthread_self would return.
> >
> > And how's that useful?
> 
> Sometimes that's very useful.
> 
> One example is where thread has performed some logging with
> its pthread_self, and you are now trying to figure out which
> thread that was.
> 
> Another is when you are debugging a deadlock, and want to know
> who is waiting on the given lock (thread ids of waiters are
> stored somewhere in mutex_t, IIRC).

Thanks for explaining.

Would it be a good idea to mention this in the manual?

Re: improved thread id reporting

[Doug Evans]

On Sat, Apr 4, 2009 at 6:11 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote:
>> > That said, if it's possible to print them without creating additional
>> > line breaks on an 80-column wide screen, I have no objections.
>> >
>> >> To fix (1) I'd like to simply remove the pthread id from the output.
>> >
>> > I think that's a bad idea.
>>
>> Even as a user-settable option?
>
> IMO, yes.  I don't think we need more settable options for details of
> output formatting; 98% or so of users will use the default, so that's
> the part that matters.

Oh well, 2 out of 3 ...
[Modulo one could provide a command to look up the pthread id given
the thread number, or provide an option to "info threads" to include
or not include it.  I'm just mentioning that for completeness sake
though.]

Question: Why does remote.c print pid.tid? [ref: remote_pid_to_str]
[I know I said it's kinda nice, but I still have a question.]

IOW, if printing pid is good for remote.c then why isn't it good for non-remote?
And if it's not good for non-remote, then why is it good for remote?
[I'm specifically referring to the linux case, but I'm guessing the
same applies to any gdbserver situation where one _could_ debug
locally as well.]
In the linux case at least the difference doesn't seem warranted
(except as some compromise, but why compromise?).

windows-nat.c:windows_pid_to_str, for example, prints pid.hex-tid.  In
the windows case is pid the same for every thread? (in the
non-multiprocess case)  Is there a case (windows or otherwise) where
pid _could_ be different for different threads in the non-multiprocess
case?  I'd expect not (gdb pretty much assumes ptid.pid is the same
for all threads in a process, right?), but please let me know if I'm
wrong.

So if one were to start over, it seems like the printing of the pid
for every thread is better left to something else ("info proc pid" or
some such?  If "proc" has too much of a linux connotation (/proc,
et.al.) then maybe "info inferior pid"?  And if something like that
makes sense, can we remove the printing of pid from multi-threaded
target_pid_to_str's and remote_pid_to_str?

It seems like the pretty-printing of a ptid_t is not a property of the
target, per se (to the extent that all else being equal there doesn't
seem to be a justification for printing local linux ptids different
from remote linux ptids - I gather there was an implementation problem
in communicating remote pthread_t's over the remote protocol, but I'm
guessing what's there now is a compromise and not the preferred
choice).
I can't think of an existing place to move target_pid_to_str though.  Blech.
And there's nothing else on the target stack for remote_pid_to_str to
defer to; IWBN if we could somehow teach it to print what the local
version would print.

Re: improved thread id reporting

[Paul Pluzhnikov]

On Sun, Apr 5, 2009 at 11:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> Would it be a good idea to mention this in the manual?

Something like this:

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.578
diff -u -r1.578 gdb.texinfo
--- gdb.texinfo	2 Apr 2009 15:56:08 -0000	1.578
+++ gdb.texinfo	5 Apr 2009 19:05:58 -0000
@@ -2469,11 +2469,14 @@
 @sc{gnu}/Linux, you might see

 @smallexample
-[New Thread 46912507313328 (LWP 25582)]
+[New Thread 0x7f1bad6cd6d0 (LWP 17573)]
 @end smallexample

 @noindent
-when @value{GDBN} notices a new thread.  In contrast, on an SGI system,
+when @value{GDBN} notices a new thread.  The @var{systag} thread identifier
+in this case is the same as the return value from @code{pthread_self}.
+
+In contrast, on an SGI system,
 the @var{systag} is simply something like @samp{process 368}, with no
 further qualifier.



The example above changed because the format of thread-id on linux
was changed here:

linux-thread-db.c
revision 1.30
date: 2007/05/14 16:52:12;  author: drow;  state: Exp;  lines: +2 -2
        * linux-thread-db.c (thread_db_pid_to_str): Print thread IDs
        as hexadecimal.

but the manual was not updated.

-- 
Paul Pluzhnikov

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sun, 5 Apr 2009 12:21:47 -0700
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
> Cc: drow@false.org, mark.kettenis@xs4all.nl, dje@google.com,
>         gdb@sourceware.org
> 
> On Sun, Apr 5, 2009 at 11:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
> > Would it be a good idea to mention this in the manual?
> 
> Something like this:

Yes, but I also thought about telling what you and Daniel mentioned:
that the thread ID is useful when you are debugging a deadlock etc.

Thanks.

Re: improved thread id reporting

[Doug Evans]

[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]

On Sat, Apr 4, 2009 at 12:21 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Apr 04, 2009 at 09:04:30PM +0200, Mark Kettenis wrote:
>> > Date: Sat,  4 Apr 2009 11:46:04 -0700 (PDT)
>> > From: dje@google.com (Doug Evans)
>> >
>> > Hi.
>> >
>> > GDB's current reporting of thread ids has (at least) three problems (IMO):
>> > 1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio.
>>
>> Uh?  I'd say it has a very high S/N ratio; it's the only thing that
>> you can actually use to identify a thread to a particular thread
>> created by the code you're debugging.
>>
>> Also realize that whatever is printed now between () is OS-specific
>> information that varies from OS to OS and may even be completely
>> absent in the case of user-level threads libraries.
>
> I agree with Mark.  I think the existing IDs are quite handy.
>
>> > 2) When switching to a thread IWBN to also report the thread being switched
>> >    from, otherwise one has to scrollback through the session to find it
>> >    (assuming that's even possible).
>>
>> That's not an unreasonable suggestion.
>
> Agreed, although I'm curious what people think of "to X from Y" vs
> "from Y to X" - I found your sample visually confusing.
>
>> > 3) When reporting thread ids the only usable number in the gdb session
>> >    (gdb's internal thread number) is not included.
>>
>> I don't consider this to be a big issue.  If I need a GDB internal
>> thread number, I find it no problem to just use the "info threads"
>> command and make decisions based on that.  I'd expect that to be much
>> more convenient than scrollback through the session ;)
>>
>> That said, if it's possible to print them without creating additional
>> line breaks on an 80-column wide screen, I have no objections.
>
> I'd find these helpful.

Attached is a simplistic patch to help illustrate the challenge.

Here is an example session that prints from/to and the thread number
in "[New ...", "[Switching ...", etc. messages.
I can think of two issues with the patch:
1) Printing "[tT]hread" twice in one line is a bit annoying.
2) Spreading from/to over two lines is a bit annoying.

Fixing (1) might simply involve agreeing on a way to add the thread
number to the text without the additional word "thread".  [Having all
the *_pid_to_str routines print "Thread" is getting in the way.]

I can fix (2), but I can't think of a way to fix it that would be
approved.  Suggestions?

If we can agree on what the output should look like, I'll submit a
patch for approval.

Comments?

gdb$ ./gdb -nx testsuite/gdb.threads/interrupted-hand-call
GNU gdb (GDB) 6.8.50.20090404-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) b thread_entry
Breakpoint 1 at 0x40040a: file
../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c,
line 77.
(gdb) r
Starting program:
/usr/local/g3/gnu/sourceware/thread-id/build/obj64/gdb/testsuite/gdb.threads/interrupted-hand-call
[Thread debugging using libthread_db enabled]
[New thread #2, Thread 0x40800960 (LWP 14406)]
[New thread #3, Thread 0x41001960 (LWP 14407)]
[Switching from thread #1, Thread 0x2aaaab6b0f30 (LWP 14403)
             to thread #2, Thread 0x40800960 (LWP 14406)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77        incr_thread_count ();
(gdb) c
Continuing.
[Switching from thread #2, Thread 0x40800960 (LWP 14406)
             to thread #3, Thread 0x41001960 (LWP 14407)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77        incr_thread_count ();
(gdb) c
Continuing.
[New thread #4, Thread 0x41802960 (LWP 14408)]
[Switching from thread #3, Thread 0x41001960 (LWP 14407)
             to thread #4, Thread 0x41802960 (LWP 14408)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77        incr_thread_count ();
(gdb) c
Continuing.
[New thread #5, Thread 0x42003960 (LWP 14409)]
[Switching from thread #4, Thread 0x41802960 (LWP 14408)
             to thread #5, Thread 0x42003960 (LWP 14409)]

Breakpoint 1, thread_entry (unused=0x0)
    at ../../../../src/gdb/testsuite/gdb.threads/interrupted-hand-call.c:77
77        incr_thread_count ();
(gdb) c
Continuing.
[Thread #4, Thread 0x41802960 (LWP 14408) exited]
[Thread #3, Thread 0x41001960 (LWP 14407) exited]
[Thread #2, Thread 0x40800960 (LWP 14406) exited]
[Thread #5, Thread 0x42003960 (LWP 14409) exited]

Program exited normally.

[-- Attachment #2: print-thread-num.patch.txt --]
[-- Type: text/plain, Size: 4502 bytes --]

Index: inf-ttrace.c
===================================================================
RCS file: /cvs/src/src/gdb/inf-ttrace.c,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 inf-ttrace.c
--- inf-ttrace.c	17 Mar 2009 19:28:09 -0000	1.44
+++ inf-ttrace.c	5 Apr 2009 20:13:25 -0000
@@ -1081,9 +1081,10 @@ inf_ttrace_wait (struct target_ops *ops,
       return ptid;
 
     case TTEVT_LWP_EXIT:
-      if (print_thread_events)
-	printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (ptid));
       ti = find_thread_pid (ptid);
+      if (print_thread_events)
+	printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+			   ti->num, target_pid_to_str (ptid));
       gdb_assert (ti != NULL);
       ((struct inf_ttrace_private_thread_info *)ti->private)->dying = 1;
       inf_ttrace_num_lwps--;
@@ -1097,10 +1098,10 @@ inf_ttrace_wait (struct target_ops *ops,
     case TTEVT_LWP_TERMINATE:
       lwpid = tts.tts_u.tts_thread.tts_target_lwpid;
       ptid = ptid_build (tts.tts_pid, lwpid, 0);
-      if (print_thread_events)
-	printf_unfiltered(_("[%s has been terminated]\n"),
-			  target_pid_to_str (ptid));
       ti = find_thread_pid (ptid);
+      if (print_thread_events)
+	printf_unfiltered(_("[Thread #%d, %s has been terminated]\n"),
+			  ti->num, target_pid_to_str (ptid));
       gdb_assert (ti != NULL);
       ((struct inf_ttrace_private_thread_info *)ti->private)->dying = 1;
       inf_ttrace_num_lwps--;
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.367
diff -u -p -u -p -r1.367 infrun.c
--- infrun.c	25 Mar 2009 21:53:10 -0000	1.367
+++ infrun.c	5 Apr 2009 20:13:25 -0000
@@ -4274,7 +4274,11 @@ normal_stop (void)
       && last.kind != TARGET_WAITKIND_EXITED)
     {
       target_terminal_ours_for_output ();
-      printf_filtered (_("[Switching to %s]\n"),
+      printf_filtered (_("[Switching from thread #%d, %s\n"),
+		       pid_to_thread_id (previous_inferior_ptid),
+		       target_pid_to_str (previous_inferior_ptid));
+      printf_filtered (_("             to thread #%d, %s]\n"),
+		       pid_to_thread_id (inferior_ptid),
 		       target_pid_to_str (inferior_ptid));
       annotate_thread_changed ();
       previous_inferior_ptid = inferior_ptid;
Index: linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.128
diff -u -p -u -p -r1.128 linux-nat.c
--- linux-nat.c	1 Apr 2009 19:07:50 -0000	1.128
+++ linux-nat.c	5 Apr 2009 20:13:25 -0000
@@ -1159,7 +1159,8 @@ exit_lwp (struct lwp_info *lp)
   if (th)
     {
       if (print_thread_events)
-	printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (lp->ptid));
+	printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+			   th->num, target_pid_to_str (lp->ptid));
 
       delete_thread (lp->ptid);
     }
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.102
diff -u -p -u -p -r1.102 procfs.c
--- procfs.c	17 Mar 2009 19:28:09 -0000	1.102
+++ procfs.c	5 Apr 2009 20:13:25 -0000
@@ -4046,7 +4046,8 @@ wait_again:
 		if (syscall_is_lwp_exit (pi, what))
 		  {
 		    if (print_thread_events)
-		      printf_unfiltered (_("[%s exited]\n"),
+		      printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+					 pid_to_thread_id (retval),
 					 target_pid_to_str (retval));
 		    delete_thread (retval);
 		    status->kind = TARGET_WAITKIND_SPURIOUS;
@@ -4182,7 +4183,8 @@ wait_again:
 		else if (syscall_is_lwp_exit (pi, what))
 		  {
 		    if (print_thread_events)
-		      printf_unfiltered (_("[%s exited]\n"),
+		      printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+					 pid_to_thread_id (retval),
 					 target_pid_to_str (retval));
 		    delete_thread (retval);
 		    status->kind = TARGET_WAITKIND_SPURIOUS;
Index: thread.c
===================================================================
RCS file: /cvs/src/src/gdb/thread.c,v
retrieving revision 1.109
diff -u -p -u -p -r1.109 thread.c
--- thread.c	31 Mar 2009 15:23:57 -0000	1.109
+++ thread.c	5 Apr 2009 20:13:25 -0000
@@ -211,7 +211,8 @@ add_thread_with_info (ptid_t ptid, struc
   result->private = private;
 
   if (print_thread_events)
-    printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));
+    printf_unfiltered (_("[New thread #%d, %s]\n"),
+		       result->num, target_pid_to_str (ptid));
 
   annotate_new_thread ();
   return result;

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sun, 5 Apr 2009 13:36:06 -0700
> From: Doug Evans <dje@google.com>
> 
> [Switching from thread #1, Thread 0x2aaaab6b0f30 (LWP 14403)
>              to thread #2, Thread 0x40800960 (LWP 14406)]

Maybe

  [Switching from thread 1, ID 0x2aaaab6b0f30 (LWP 14403)
               to thread 2, ID 0x40800960 (LWP 14406)]

and

  [Thread 4, ID 0x41802960 (LWP 14408) exited]

is slightly better, as it solves issue 1).  As for 2), I personally
don't mind it too much.  But if we want a single line, I can suggest

  [Thread switch: #1 (ID 0x2aaaab6b0f30, LWP 14403) -> #2 (ID 0x40800960, LWP 14406)]

Re: improved thread id reporting

[Daniel Jacobowitz]

On Sun, Apr 05, 2009 at 01:36:06PM -0700, Doug Evans wrote:
> Attached is a simplistic patch to help illustrate the challenge.
> 
> Here is an example session that prints from/to and the thread number
> in "[New ...", "[Switching ...", etc. messages.
> I can think of two issues with the patch:
> 1) Printing "[tT]hread" twice in one line is a bit annoying.
> 2) Spreading from/to over two lines is a bit annoying.

What do you think of this?  On the theory that you can go look up
thread #2, either in 'info threads' or in a previous notification:

[Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)]

Or, migrating the "Thread" out:

[Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)]

But that might be tricky with multi-process, some ptid_t's are not
threads.

-- 
Daniel Jacobowitz
CodeSourcery

Re: improved thread id reporting

[Mark Kettenis]

> Date: Mon, 06 Apr 2009 05:56:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>

> is slightly better, as it solves issue 1).  As for 2), I personally
> don't mind it too much.  But if we want a single line, I can suggest
> 
>   [Thread switch: #1 (ID 0x2aaaab6b0f30, LWP 14403) -> #2 (ID 0x40800960, LWP 14406)]

That's still longer than a single 80-column line :(

Re: improved thread id reporting

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> +      printf_filtered (_("[Switching from thread #%d, %s\n"),
Doug> +		       pid_to_thread_id (previous_inferior_ptid),
Doug> +		       target_pid_to_str (previous_inferior_ptid));
Doug> +      printf_filtered (_("             to thread #%d, %s]\n"),

This approach to lining things up is not i18n-friendly.  You might be
able to use wrap_here, but I'm not sure that is any friendlier, as it
means you must break up the message.

Tom

Re: improved thread id reporting

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Date: Mon, 06 Apr 2009 14:07:58 -0600
> 
> >>>>> "Doug" == Doug Evans <dje@google.com> writes:
> 
> Doug> +      printf_filtered (_("[Switching from thread #%d, %s\n"),
> Doug> +		       pid_to_thread_id (previous_inferior_ptid),
> Doug> +		       target_pid_to_str (previous_inferior_ptid));
> Doug> +      printf_filtered (_("             to thread #%d, %s]\n"),
> 
> This approach to lining things up is not i18n-friendly.

Sorry, I'm probably too dense today: why not?  If you are thinking
about the number of blanks, then the translated second message can
change their amount as appropriate, no?

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Mon, 6 Apr 2009 09:38:59 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: dje@google.com, gdb@sourceware.org
> 
> > Date: Mon, 06 Apr 2009 05:56:45 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> 
> > is slightly better, as it solves issue 1).  As for 2), I personally
> > don't mind it too much.  But if we want a single line, I can suggest
> > 
> >   [Thread switch: #1 (ID 0x2aaaab6b0f30, LWP 14403) -> #2 (ID 0x40800960, LWP 14406)]
> 
> That's still longer than a single 80-column line :(

Only for very large IDs (one of the two in this example).  How
frequent is that?

Re: improved thread id reporting

[Eli Zaretskii]

> Date: Sun, 5 Apr 2009 23:33:00 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> What do you think of this?  On the theory that you can go look up
> thread #2, either in 'info threads' or in a previous notification:
> 
> [Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)]
> 
> Or, migrating the "Thread" out:
> 
> [Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)]

Looks good to me.

Re: improved thread id reporting

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Doug> +      printf_filtered (_("[Switching from thread #%d, %s\n"),
Doug> +		       pid_to_thread_id (previous_inferior_ptid),
Doug> +		       target_pid_to_str (previous_inferior_ptid));
Doug> +      printf_filtered (_("             to thread #%d, %s]\n"),

>> This approach to lining things up is not i18n-friendly.

Eli> Sorry, I'm probably too dense today: why not?  If you are thinking
Eli> about the number of blanks, then the translated second message can
Eli> change their amount as appropriate, no?

Only if the translator knows to do that.

Tom

Re: improved thread id reporting

[Doug Evans]

On Mon, Apr 6, 2009 at 2:46 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>
> Doug> +      printf_filtered (_("[Switching from thread #%d, %s\n"),
> Doug> +                pid_to_thread_id (previous_inferior_ptid),
> Doug> +                target_pid_to_str (previous_inferior_ptid));
> Doug> +      printf_filtered (_("             to thread #%d, %s]\n"),
>
>>> This approach to lining things up is not i18n-friendly.
>
> Eli> Sorry, I'm probably too dense today: why not?  If you are thinking
> Eli> about the number of blanks, then the translated second message can
> Eli> change their amount as appropriate, no?
>
> Only if the translator knows to do that.

I realize this is digressing but y'all are too. :-)
I was thinking that the translation might just punt on the spacing, I
was more worried about some language that preferred to/from, but since
this was just an example I wasn't worried about such issues.

Re: improved thread id reporting

[Doug Evans]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Sun, Apr 5, 2009 at 8:33 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Apr 05, 2009 at 01:36:06PM -0700, Doug Evans wrote:
>> Attached is a simplistic patch to help illustrate the challenge.
>>
>> Here is an example session that prints from/to and the thread number
>> in "[New ...", "[Switching ...", etc. messages.
>> I can think of two issues with the patch:
>> 1) Printing "[tT]hread" twice in one line is a bit annoying.
>> 2) Spreading from/to over two lines is a bit annoying.
>
> What do you think of this?  On the theory that you can go look up
> thread #2, either in 'info threads' or in a previous notification:
>
> [Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)]

"works for me"

> Or, migrating the "Thread" out:
>
> [Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)]
>
> But that might be tricky with multi-process, some ptid_t's are not
> threads.

It's not clear how multi-process is going to work yet (or more likely
I've forgotten).  I played with attaching and running several
processes via gdbserver and all processes appear in "info threads".
[sidebar: I wouldn't mind "info threads" just showing the threads of
the current process, otherwise it might get confusing.  And given that
"info inferiors" is used to show all the processes IWBN if "inferior
N" switched to the specified process; a straightforward and intuitive
mapping from "info threads" + "thread N".]

How about this?

[-- Attachment #2: gdb-090507-thread-id-1.patch.txt --]
[-- Type: text/plain, Size: 4857 bytes --]

2009-05-07  Doug Evans  <dje@google.com>

	* infrun.c (normal_stop): Print gdb thread number of thread being
	switched away from and to.
	* inf-ttrace.c (inf_ttrace_wait): Include gdb thread number in
	thread event messages.
	* linux-nat.c (exit_lwp): Ditto.
	* procfs.c (procfs_wait): Ditto.
	* thread.c (add_thread_with_info): Ditto.

Index: inf-ttrace.c
===================================================================
RCS file: /cvs/src/src/gdb/inf-ttrace.c,v
retrieving revision 1.44
diff -u -p -r1.44 inf-ttrace.c
--- inf-ttrace.c	17 Mar 2009 19:28:09 -0000	1.44
+++ inf-ttrace.c	8 May 2009 04:53:39 -0000
@@ -1081,10 +1081,11 @@ inf_ttrace_wait (struct target_ops *ops,
       return ptid;
 
     case TTEVT_LWP_EXIT:
-      if (print_thread_events)
-	printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (ptid));
       ti = find_thread_pid (ptid);
       gdb_assert (ti != NULL);
+      if (print_thread_events)
+	printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+			   ti->num, target_pid_to_str (ptid));
       ((struct inf_ttrace_private_thread_info *)ti->private)->dying = 1;
       inf_ttrace_num_lwps--;
       /* Let the thread really exit.  */
@@ -1097,11 +1098,11 @@ inf_ttrace_wait (struct target_ops *ops,
     case TTEVT_LWP_TERMINATE:
       lwpid = tts.tts_u.tts_thread.tts_target_lwpid;
       ptid = ptid_build (tts.tts_pid, lwpid, 0);
-      if (print_thread_events)
-	printf_unfiltered(_("[%s has been terminated]\n"),
-			  target_pid_to_str (ptid));
       ti = find_thread_pid (ptid);
       gdb_assert (ti != NULL);
+      if (print_thread_events)
+	printf_unfiltered (_("[Thread #%d, %s has been terminated]\n"),
+			   ti->num, target_pid_to_str (ptid));
       ((struct inf_ttrace_private_thread_info *)ti->private)->dying = 1;
       inf_ttrace_num_lwps--;
 
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.371
diff -u -p -r1.371 infrun.c
--- infrun.c	5 May 2009 13:24:48 -0000	1.371
+++ infrun.c	8 May 2009 04:53:39 -0000
@@ -4299,7 +4299,11 @@ normal_stop (void)
       && last.kind != TARGET_WAITKIND_EXITED)
     {
       target_terminal_ours_for_output ();
-      printf_filtered (_("[Switching to %s]\n"),
+      /* It is useful to the user to print the gdb thread numbers we're
+	 switching away from and to.  */
+      printf_filtered (_("[Switching from thread #%d to thread #%d, %s]\n"),
+		       pid_to_thread_id (previous_inferior_ptid),
+		       pid_to_thread_id (inferior_ptid),
 		       target_pid_to_str (inferior_ptid));
       annotate_thread_changed ();
       previous_inferior_ptid = inferior_ptid;
Index: linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.128
diff -u -p -r1.128 linux-nat.c
--- linux-nat.c	1 Apr 2009 19:07:50 -0000	1.128
+++ linux-nat.c	8 May 2009 04:53:40 -0000
@@ -1159,7 +1159,8 @@ exit_lwp (struct lwp_info *lp)
   if (th)
     {
       if (print_thread_events)
-	printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (lp->ptid));
+	printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+			   th->num, target_pid_to_str (lp->ptid));
 
       delete_thread (lp->ptid);
     }
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.106
diff -u -p -r1.106 procfs.c
--- procfs.c	6 May 2009 17:18:52 -0000	1.106
+++ procfs.c	8 May 2009 04:53:40 -0000
@@ -4046,7 +4046,8 @@ wait_again:
 		if (syscall_is_lwp_exit (pi, what))
 		  {
 		    if (print_thread_events)
-		      printf_unfiltered (_("[%s exited]\n"),
+		      printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+					 pid_to_thread_id (retval),
 					 target_pid_to_str (retval));
 		    delete_thread (retval);
 		    status->kind = TARGET_WAITKIND_SPURIOUS;
@@ -4182,7 +4183,8 @@ wait_again:
 		else if (syscall_is_lwp_exit (pi, what))
 		  {
 		    if (print_thread_events)
-		      printf_unfiltered (_("[%s exited]\n"),
+		      printf_unfiltered (_("[Thread #%d, %s exited]\n"),
+					 pid_to_thread_id (retval),
 					 target_pid_to_str (retval));
 		    delete_thread (retval);
 		    status->kind = TARGET_WAITKIND_SPURIOUS;
Index: thread.c
===================================================================
RCS file: /cvs/src/src/gdb/thread.c,v
retrieving revision 1.110
diff -u -p -r1.110 thread.c
--- thread.c	5 May 2009 13:24:49 -0000	1.110
+++ thread.c	8 May 2009 04:53:40 -0000
@@ -211,7 +211,8 @@ add_thread_with_info (ptid_t ptid, struc
   result->private = private;
 
   if (print_thread_events)
-    printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));
+    printf_unfiltered (_("[New thread #%d, %s]\n"),
+		       result->num, target_pid_to_str (ptid));
 
   annotate_new_thread ();
   return result;