This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: improved thread id reporting


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: print-thread-num.patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]