From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11694 invoked by alias); 20 Feb 2003 19:32:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15298 invoked from network); 20 Feb 2003 19:26:42 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 20 Feb 2003 19:26:42 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18lyEM-0001TQ-00; Thu, 20 Feb 2003 15:27:46 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lwL8-0004wJ-00; Thu, 20 Feb 2003 14:26:38 -0500 Date: Thu, 20 Feb 2003 19:32:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: GDB Patches Subject: Re: [patch/rfc] Add a sentinel frame Message-ID: <20030220192638.GC18821@nevyn.them.org> Mail-Followup-To: Andrew Cagney , GDB Patches References: <20030219165623.GA7961@nevyn.them.org> <3E53BBCB.2010003@redhat.com> <20030219171700.GA8736@nevyn.them.org> <3E53C416.30809@redhat.com> <20030219175654.GA10010@nevyn.them.org> <3E53CFB8.8070201@redhat.com> <20030219185202.GA11371@nevyn.them.org> <3E53E8B8.10203@redhat.com> <20030219203937.GA14890@nevyn.them.org> <3E53F660.6090809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E53F660.6090809@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00488.txt.bz2 On Wed, Feb 19, 2003 at 04:25:52PM -0500, Andrew Cagney wrote: > > >Oh, but you're misunderstanding. There's more than one frame in there. > >The call stack in glibc looks like: > > _start > > calls __libc_start_main > > calls main > > Nope, that assumes glibc. Remember, i debugged this using the d10v. No, it doesn't assume glibc, it uses glibc as an example. That check would prevent backtraces entering _start; on the d10v, that would override backtrace-beyond-main, but on a glibc system, it wouldn't. > >_start is written in assembly; it generally doesn't have a frame worth > >talking about. Even if we want to show __libc_start_main, we can't > >safely backtrace into _start. That's what the inside_entry_file > >(frame_pc_unwind (fi)) is for. > > Why not? If someone wants to do that, why should we stand in their way :-) ... uhm, I guess, I don't really find that convincing. The check was there because it won't work. But now that it's not the default I don't care if you want to break it. > >The missing test I mentioned above inside_entry_func, not > >inside_entry_file. Where'd that go? > > Left until something that does need it surfaces. If you're going to yank code that way please add a comment saying so, before you yank frame_chain_valid as dead and someone else discovers all the inside_entry_func support is now dead code and purges it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer