This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Making "info thread" sane
- From: Eli Zaretskii <eliz at elta dot co dot il>
- To: George Anzinger <george at mvista dot com>
- Cc: cagney at gnu dot org, drow at mvista dot com,gdb at sources dot redhat dot com
- Date: 03 Mar 2004 08:01:58 +0200
- Subject: Re: Making "info thread" sane
- References: <20040227212301.GC1052@smtp.west.cox.net> <20040227235059.GG425@elf.ucw.cz> <403FEA02.6040506@mvista.com> <200403011454.35346.amitkale@emsyssoft.com> <4044FEDE.5000105@mvista.com> <20040302214535.GA24405@nevyn.them.org> <40450749.7020304@mvista.com> <20040302221718.GA26931@nevyn.them.org> <404515AA.8040709@mvista.com> <404517E8.1020708@gnu.org> <4045236B.3060104@mvista.com>
- Reply-to: Eli Zaretskii <eliz at elta dot co dot il>
> Date: Tue, 02 Mar 2004 16:14:35 -0800
> From: George Anzinger <george@mvista.com>
>
> Andrew Cagney wrote:
> > Um, can you explain the problem?
>
> The problem is that, for most threaded apps and for the kernel which treats each
> task as a thread, the "info thread" command gives a list of threads all stopped
> in the context switch code. What is desired is to do one or more "up" commands
> and report info on this location.
Can you explain why GDB should know about this? The user could
always "up" manually or via the GDB's scripting language, right?
As I see it, the situation is analogous to when you, e.g., attach GDB
to a running process, and the backtrace shows that it is stuck in
some uninteresting system call. The very next thing to do is either
"up" or step the program until it winds up in some application code
that _is_ interesting. We don't request GDB to show the application
code automagically, do we?