Re: Making "info thread" sane

[George Anzinger <george@mvista.com>]

Change the topic to make more sense and include the list...

Daniel Jacobowitz wrote:
> 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.

Well my origional suggestion was to set it up using set commands, i.e. most 
likely in the users .gdbinit file.  But I really do think the stub has a more 
detailed knowledge of what is up.  For example, if the stub is kgdb, i.e. the 
kernel, or a gdb stub in a target machines user space, doesn't gdb see the same 
thing?  And these two environments should really be treated differently WRT how 
far back to take the thead.

Another thought is to provide entry points in the target that define the area 
that needs to be backed out of.  Gdb already knows about the alloc entry point 
so this is not too far fetched.  Something like:
gdb_thread_switch_begin and gdb_thread_switch_end

-- 
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