From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23400 invoked by alias); 12 Mar 2004 00:24:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23292 invoked from network); 12 Mar 2004 00:24:15 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 12 Mar 2004 00:24:15 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA03759; Thu, 11 Mar 2004 16:24:09 -0800 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i2C0O5BA021328; Thu, 11 Mar 2004 16:24:06 -0800 Message-ID: <40510325.4070101@mvista.com> Date: Fri, 12 Mar 2004 00:24:00 -0000 From: George Anzinger Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Making "info thread" sane References: <403FEA02.6040506@mvista.com> <200403011454.35346.amitkale@emsyssoft.com> <4044FEDE.5000105@mvista.com> <20040302214535.GA24405@nevyn.them.org> <40450749.7020304@mvista.com> <20040302221718.GA26931@nevyn.them.org> <404515AA.8040709@mvista.com> <404517E8.1020708@gnu.org> <4045236B.3060104@mvista.com> <20040303142842.GA12777@nevyn.them.org> <4046267E.1080808@mvista.com> <404629E3.5020906@gnu.org> <40465651.900@mvista.com> <404D1CFF.6070209@gnu.org> In-Reply-To: <404D1CFF.6070209@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00112.txt.bz2 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' * '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 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