From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1611 invoked by alias); 3 Mar 2004 22:04:12 -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 1598 invoked from network); 3 Mar 2004 22:04:09 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 3 Mar 2004 22:04:09 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA01238; Wed, 3 Mar 2004 14:04:05 -0800 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i23M415O003121; Wed, 3 Mar 2004 14:04:02 -0800 Message-ID: <40465651.900@mvista.com> Date: Wed, 03 Mar 2004 22:04: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> In-Reply-To: <404629E3.5020906@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00029.txt.bz2 Andrew Cagney wrote: > >>> The interesting thing about George's situation is that there's a lot of >>> threads (basically, all but one of them) that we know in advance will >>> be stuck in context switching code. One of the nice things about info >>> threads is that it shows you the current frame for all your threads; >>> but in this case, that's not really very interesting information. >>> >>> If we could find out where those threads were _before_ they switched >>> out, now, that would make for an interesting overview. >> >> >> >> Also, I am not apposed to a macro solution. But, as far as I know the >> macros are a bit weak. For example, the info thread command lists the >> thread number, pid, and an info field (which in my case is the task >> name from the kernel task struct). So how would a macro keep this >> info intact and display it along with the "up" result on the same >> line? In my thoughts on this I have considered a maintaince request >> to the host which would return the pid and the info field, .... > > >> I also wonder how to determine, when stepping through the threads, >> that that was the last one. As far as I know the top thread number is >> not available as a $var (but that would be nice for other macros as >> well). > > > Sorry, I'm lost here. Can you perhaphs sketch out how you'd expect GDB, > the user, and the target to interact? 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. 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). 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? 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. 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. -- 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