From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32579 invoked by alias); 3 Mar 2004 00:14:43 -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 32560 invoked from network); 3 Mar 2004 00:14:39 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 3 Mar 2004 00:14:39 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA18542; Tue, 2 Mar 2004 16:14:37 -0800 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i230EZ5O004406; Tue, 2 Mar 2004 16:14:36 -0800 Message-ID: <4045236B.3060104@mvista.com> Date: Wed, 03 Mar 2004 00:14: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 , gdb@sources.redhat.com Subject: Re: Making "info thread" sane 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> In-Reply-To: <404517E8.1020708@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00021.txt.bz2 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. The proposal I made was to define a set command to specify an address range that "info thread" would "back" out of (using internal "up" commands), or to provide a fixed number of "up"s, depending on which made the most sense for the application. For the kernel, the range is what is currently used when it reports thread information (internal kernel code, not kgdb or any such). In the kgdb I currently have in the -mm kernel, I back this stuff up in the kgdb stub, but it really doesn't have enough info to always do it right (but I have not seen it fail yet :). Gdb, on the other hand, has the full frame debug info and can do it correctly. Please understand, if we then to a thread X command, we want to start in the switch code, it is only for the thread info that we want the back out. I have proposed writing this code. Daniel suggested that we discuss it a bit more to make sure it all makes sense. I think his concern was with how we tell gdb what the right thing to do is. I don't know how things like this are passed to gdb at this time, but I have been wondering about a mech. to communicate with stubs. Such an interface could pass back the bounds to use, for example. I suppose we could bury this info in the thread info preamble record... On the other hand, you probably don't want to let me loose in gdb. No telling what I might add :) -- 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