From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28411 invoked by alias); 3 Mar 2004 15:08:00 -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 28401 invoked from network); 3 Mar 2004 15:07:59 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 15:07:59 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 187A22B92; Wed, 3 Mar 2004 10:07:55 -0500 (EST) Message-ID: <4045F4CA.5060102@gnu.org> Date: Wed, 03 Mar 2004 15:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Eli Zaretskii , George Anzinger , 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/msg00024.txt.bz2 > 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? Right. Commands like: info threads thread 1 info frame should all give consistent output. As they say, don't lie to the user. > 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. It should be possible to script this (I suspect it isn't and hence part of the problem). For instance something like: (gdb) define kthread-info thread apply all try set $skip 0 if $frame.func == &func you want to ignore set $skip = $skip + 1 end silent up $skip thread info silent down $skip end end There are patches for "try" and "$func" lurking, silent is easy (if it makes sense). Wonder if the parser allows "thread apply all try ...end" I know other kernels have, over time, accumulated a bunch of scripts for dumping out internal structures in human readable form. I think this goes into that category. enjoy, Andrew