improved thread id reporting
Daniel Jacobowitz
drow@false.org
Sat Apr 4 20:40:00 GMT 2009
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
More information about the Gdb
mailing list