From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9915 invoked by alias); 3 Mar 2004 06:01:47 -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 9906 invoked from network); 3 Mar 2004 06:01:44 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 3 Mar 2004 06:01:44 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1AyPQf-00023B-V8; Wed, 03 Mar 2004 01:00:26 -0500 Date: Wed, 03 Mar 2004 06:01:00 -0000 Message-Id: From: Eli Zaretskii To: George Anzinger CC: cagney@gnu.org, drow@mvista.com,gdb@sources.redhat.com In-reply-to: <4045236B.3060104@mvista.com> (message from George Anzinger on Tue, 02 Mar 2004 16:14:35 -0800) Subject: Re: Making "info thread" sane Reply-to: Eli Zaretskii References: <20040227212301.GC1052@smtp.west.cox.net> <20040227235059.GG425@elf.ucw.cz> <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> X-SW-Source: 2004-03/txt/msg00022.txt.bz2 > 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?