This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Making "info thread" sane
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