Re: Making "info thread" sane

George Anzinger
2004-03-03T00:14:43Z

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