From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18589 invoked by alias); 3 Mar 2004 18:40:08 -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 18531 invoked from network); 3 Mar 2004 18:40:05 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 3 Mar 2004 18:40:05 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA22435; Wed, 3 Mar 2004 10:40:02 -0800 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i23Idw5O020493; Wed, 3 Mar 2004 10:39:58 -0800 Message-ID: <4046267E.1080808@mvista.com> Date: Wed, 03 Mar 2004 18:40: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: Daniel Jacobowitz CC: Eli Zaretskii , cagney@gnu.org, 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> In-Reply-To: <20040303142842.GA12777@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00027.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Mar 03, 2004 at 08:01:58AM +0200, Eli Zaretskii wrote: > >>>Date: Tue, 02 Mar 2004 16:14:35 -0800 >>>From: George Anzinger >>> >>>Andrew Cagney wrote: >>> >>>>Um, can you explain the problem? >>> >>>The problem is that, for most threaded apps and for the kernel which treats each >>>task as a thread, the "info thread" command gives a list of threads all stopped >>>in the context switch code. What is desired is to do one or more "up" commands >>>and report info on this location. >> >>Can you explain why GDB should know about this? The user could >>always "up" manually or via the GDB's scripting language, right? >> >>As I see it, the situation is analogous to when you, e.g., attach GDB >>to a running process, and the backtrace shows that it is stuck in >>some uninteresting system call. The very next thing to do is either >>"up" or step the program until it winds up in some application code >>that _is_ interesting. We don't request GDB to show the application >>code automagically, do we? > > > 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). > -- 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