Re: Making "info thread" sane

[George Anzinger <george@mvista.com>]

Andrew Cagney wrote:
>> First, the objective is to get something like what "info thread" does 
>> but with a frame that is outside of the switch code (which may mean  
>> several frames up the stack).  I was considering a macro that would do 
>> a silent info thread followed by a loop on each discovered thread.  In 
>> your message yesterday you suggested something like:
>>
>> thread apply all try... end
>>
>> Well, I don't find "try" but the apply all seems to accept a macro as 
>> a command so I think this will do the right thing.  And up-silent does 
>> a silent up.
> 
> 
> "try" isn't seen cos the patch is sitting in the bug database :-(
> 
> I mentioned "try" as without it the command will abort on the first 
> error (e.g., corrupt stack for bad memory access).
> 
>> So, this would be my macro set:
>>
>> define do_threads
>>   thread apply all do_th_lines
>> end
>>
>> define do_th_lines
>>   while ($pc > $low_sched) && ($pc < $high_sched)
>>     up-silent
>>   end
>>   do-silent
>>   up
>> end
>>
>> What is missing are: 1) I would like to not have the newline after the
>> "Thread 1 (Thread 1):" (a minor point, but with 100 threads it adds 
>> up) and
> 
>  > 2) I would like to have the result of the "ThreadExtraInfo" on the 
> same line (as the info thread command does).
> 
> Can you post the output so we can see exactly what you mean here?

I haven't got it all working as yet, but the "thread apply all"
puts out something like:
  Thread 1 (Thread 1):
for each thread.  An option I would like is for this to not have new line so I 
can add to it, something like:
Thread 1 (Thread 1): (init) 0xff00....
and keep it all on one line.
> 
>> Nice, would be the ability to print the final up result without doing 
>> the down first.  In fact this is really needed if it turns out that we 
>> are at the first frame which would be the case for the current 
>> thread.  Is that a command I missed?
> 
> 
> You mean an abbreviated "info frame"?  Yes, using "up" to get that 
> output isn't right.

Not only isn't it right, it does not work if at the bottom of the stack.  Right 
now this is what errors out my macro set.
> 
>> I suspect that 2) can be handled by "info remote-process" with changes 
>> to the stub AND I would like this to NOT put in a linefeed.
> 
> 
> What "info remote-process" command?
To quote the source:

* This query allows the target stub to return an arbitrary string
  * (or strings) giving arbitrary information about the target process.
  * This is optional; the target stub isn't required to implement it.
  *
  * Syntax: qfProcessInfo        request first string
  *         qsProcessInfo        request subsequent string
  * reply:  'O'<hex-encoded-string>
  *         'l'                  last reply (empty)
  */

I have not, as yet, coded this into my stub so I don't know what gdb does with 
it, but, again, I want a way to suppress the new line that I suspect it attaches.

In the case of kgdb, what I want to return here is the task name and put it in 
the threads report much as the extra thread info is put in the info threads report.
> 
>> It would appear that this has unwound into a couple of rather simple 
>> things:
>> a) No new line capability on the "thread apply all"
>> b) No new line on "info remote-process"
>> c) Ability to do the up/down report without moving to a new frame. 
> 
> 
Actually with out c) the whole thing is a non-starter.  Is there some trick to 
make this happen today?

I think an option on the info stack command would be just the thing.  I.e. info 
stack <frame> <limit>  where limit, if present says how many frames to display 
prior to <frame>.  So info stack 3 0 would display frame 3 only while
info stack 3 2 would display frames 1,2,and 3.

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