On Wed, Mar 03, 2004 at 08:01:58AM +0200, Eli Zaretskii wrote:
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?
The interesting thing about George's situation is that there's a lot of
threads (basically, all but one of them) that we know in advance will
be stuck in context switching code. One of the nice things about info
threads is that it shows you the current frame for all your threads;
but in this case, that's not really very interesting information.
If we could find out where those threads were _before_ they switched
out, now, that would make for an interesting overview.