From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25130 invoked by alias); 2 Mar 2004 23:15:59 -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 25123 invoked from network); 2 Mar 2004 23:15:58 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 2 Mar 2004 23:15:58 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA15313; Tue, 2 Mar 2004 15:15:56 -0800 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i22NFs5O032477; Tue, 2 Mar 2004 15:15:54 -0800 Message-ID: <404515AA.8040709@mvista.com> Date: Tue, 02 Mar 2004 23:15: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 , 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> In-Reply-To: <20040302221718.GA26931@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00019.txt.bz2 Change the topic to make more sense and include the list... Daniel Jacobowitz wrote: > On Tue, Mar 02, 2004 at 02:14:33PM -0800, George Anzinger wrote: > >>Daniel Jacobowitz wrote: >> >>>On Tue, Mar 02, 2004 at 01:38:38PM -0800, George Anzinger wrote: >>> >>> >>>>A new "set thread_level" command that would take the "bt" level to >>>>use on the thread display. A new "set thread_limits command that >>>>would take two expressions that would reduce to two memory addresses. >>>> >>>>Which ever of these is entered last will be active and used by "info >>>>thread" as follows: >>>> >>>>if thread_level is active gdb will do the indicated number of "up" >>>>operations and display the result on the info thread line for that thread >>>>(note there is other info on this line that will not be changed). >>>> >>>>if thread_limits is active gdb will do 0 or more "up" commands until the >>>>resultant PC is NOT between the given limits. >>>> >>>>The kernel, at this time, has defined symbols for the thread_limits >>>>command (it is used in the kernel for its internal display of threads). >>>>I would expect that the thread_level version would be the answer for >>>>theaded application programs. >>>> >>>>Daniel, how does this sound? >>> >>> >>>I really don't have time to work on this sort of thing, unfortunately. >> >>I was thinking of doing the code.... >> >> >>>But I think it sounds terribly awkward :) What you want is a generic, >>>target specific way to specify the default current frame after the >>>target stops. The right way to do that may be with kgdb-specific >>>extensions to GDB, or not. Someone on the GDB list might have >>>comments. >> >>I would think that the problem of all threads being in the context switch >>code would be much more generic than just kgdb. >> >>As to how to set this up, I would like to see a way for stubs to query gdb >>as gdb querys stubs (although the "try this, did it fail" method is a bit >>limited in what it can do). Possibly a gdb request of the stub such as >>"tell me about your self" which is replied with by a set of couplets >>indicating what commands the sub can do and other useful info. This >>becomes a bit more of a problem when there is no stub, but I suppose gdb is >>configured to handle this sort of thing. > > > None of this should be specific to the remote protocol at all. This is > the same thing we do in C++; you say "catch throw", and what you really > want to see is one frame up from where we hit the utility function. In > that sense, it needs to be more general. And context-sensitive. > > But the question of where to make this decision - I don't think the > stub should be involved at all. Well my origional suggestion was to set it up using set commands, i.e. most likely in the users .gdbinit file. But I really do think the stub has a more detailed knowledge of what is up. For example, if the stub is kgdb, i.e. the kernel, or a gdb stub in a target machines user space, doesn't gdb see the same thing? And these two environments should really be treated differently WRT how far back to take the thead. Another thought is to provide entry points in the target that define the area that needs to be backed out of. Gdb already knows about the alloc entry point so this is not too far fetched. Something like: gdb_thread_switch_begin and gdb_thread_switch_end -- 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