improved thread id reporting
Doug Evans
dje@google.com
Sun Apr 5 01:11:00 GMT 2009
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.
More information about the Gdb
mailing list