Re: Making "info thread" sane

[George Anzinger <george at mvista dot 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.

The proposal I made was to define a set command to specify an address range that 
"info thread" would "back" out of (using internal "up" commands), or to provide 
a fixed number of "up"s, depending on which made the most sense for the application.

For the kernel, the range is what is currently used when it reports thread 
information (internal kernel code, not kgdb or any such).

In the kgdb I currently have in the -mm kernel, I back this stuff up in the kgdb 
stub, but it really doesn't have enough info to always do it right (but I have 
not seen it fail yet :).  Gdb, on the other hand, has the full frame debug info 
and can do it correctly.

Please understand, if we then to a thread X command, we want to start in the 
switch code, it is only for the thread info that we want the back out.

I have proposed writing this code.  Daniel suggested that we discuss it a bit 
more to make sure it all makes sense.  I think his concern was with how we tell 
gdb what the right thing to do is.  I don't know how things like this are passed 
to gdb at this time, but I have been wondering about a mech. to communicate with 
stubs.  Such an interface could pass back the bounds to use, for example.  I 
suppose we could bury this info in the thread info preamble record...

On the other hand, you probably don't want to let me loose in gdb.  No telling 
what I might add :)


--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml