Re: Making "info thread" sane

George Anzinger
2004-03-12T00:24:22Z

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 <limit> where limit, if present says how many frames to display
prior to . 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