Re: improved thread id reporting

[Doug Evans <dje at google dot com>]

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?