On Tue, Mar 02, 2004 at 02:14:33PM -0800, George Anzinger wrote:
Daniel Jacobowitz wrote:
On Tue, Mar 02, 2004 at 01:38:38PM -0800, George Anzinger wrote:
A new "set thread_level" command that would take the "bt" level to
use on the thread display. A new "set thread_limits command that
would take two expressions that would reduce to two memory addresses.
Which ever of these is entered last will be active and used by "info
thread" as follows:
if thread_level is active gdb will do the indicated number of "up"
operations and display the result on the info thread line for that thread
(note there is other info on this line that will not be changed).
if thread_limits is active gdb will do 0 or more "up" commands until the
resultant PC is NOT between the given limits.
The kernel, at this time, has defined symbols for the thread_limits
command (it is used in the kernel for its internal display of threads).
I would expect that the thread_level version would be the answer for
theaded application programs.
Daniel, how does this sound?
I really don't have time to work on this sort of thing, unfortunately.
I was thinking of doing the code....
But I think it sounds terribly awkward :) What you want is a generic,
target specific way to specify the default current frame after the
target stops. The right way to do that may be with kgdb-specific
extensions to GDB, or not. Someone on the GDB list might have
comments.
I would think that the problem of all threads being in the context switch
code would be much more generic than just kgdb.
As to how to set this up, I would like to see a way for stubs to query gdb
as gdb querys stubs (although the "try this, did it fail" method is a bit
limited in what it can do). Possibly a gdb request of the stub such as
"tell me about your self" which is replied with by a set of couplets
indicating what commands the sub can do and other useful info. This
becomes a bit more of a problem when there is no stub, but I suppose gdb is
configured to handle this sort of thing.
None of this should be specific to the remote protocol at all. This is
the same thing we do in C++; you say "catch throw", and what you really
want to see is one frame up from where we hit the utility function. In
that sense, it needs to be more general. And context-sensitive.
But the question of where to make this decision - I don't think the
stub should be involved at all.