From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19542 invoked by alias); 5 Feb 2002 21:57:23 -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 19473 invoked from network); 5 Feb 2002 21:57:21 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Feb 2002 21:57:21 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16YDaW-0002sd-00; Tue, 05 Feb 2002 16:57:16 -0500 Date: Tue, 05 Feb 2002 13:57:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Recognize bottom of stack on Linux Message-ID: <20020205165716.A10437@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <200202040206.VAA21952@zenia.red-bean.com> <20020203222111.A17644@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00132.txt.bz2 On Tue, Feb 05, 2002 at 02:59:39PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > On Sun, Feb 03, 2002 at 09:06:36PM -0500, Jim Blandy wrote: > > > > > > Now, some folks feel that GDB should show the whole stack, including > > > _start, __libc_start_main, and anything else that's there. However, > > > this isn't the way GDB has ever traditionally behaved on native > > > targets. So this patch makes GDB's backtraces end after main. > > > > > > 2002-02-03 Jim Blandy > > > > > > * i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain > > > after `main', not just after the compilation unit containing the > > > entry point. > > > > Shouldn't we use func_frame_chain_valid instead of > > file_frame_chain_valid instead of duplicating this? > > > > I don't understand why that function doesn't have more callers. It > > seems that at least all non-embedded targets, or at the very least all > > Linux targets, should use it. > > The following works fine for me, too: > > 2002-02-05 Jim Blandy > > * i386-linux-tdep.c (i386_linux_frame_chain): Use > func_frame_chain_valid, instead of plain inside_entry_file. I like this. The way func_frame_chain_valid should really be used is by something like: /* NOTE: tm-i386nw.h and tm-i386v4.h override this. */ set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid); (copied from i386-tdep.c). Does this patch work for you? I'm curious as to why we can't just set this universally, or at least a little more globally. Most things that have a main () use it as a normal main (). I'd propose that we set it as the default frame chain, and provide/document an option to ignore inside_main_func. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.50 diff -u -r1.50 i386-tdep.c --- i386-tdep.c 2002/01/01 16:29:43 1.50 +++ i386-tdep.c 2002/02/05 21:47:11 @@ -1324,7 +1324,7 @@ set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack); - /* NOTE: tm-i386nw.h and tm-i386v4.h override this. */ + /* NOTE: tm-i386nw.h, tm-i386v4.h, and tm-linux.h override this. */ set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid); /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h, Index: config/i386/tm-linux.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v retrieving revision 1.16 diff -u -r1.16 tm-linux.h --- config/i386/tm-linux.h 2001/11/08 00:03:52 1.16 +++ config/i386/tm-linux.h 2002/02/05 21:47:11 @@ -31,6 +31,10 @@ #include "i386/tm-i386.h" #include "tm-linux.h" +/* Use the alternate method of determining valid frame chains. */ + +#define FRAME_CHAIN_VALID(fp,fi) func_frame_chain_valid (fp, fi) + /* Register number for the "orig_eax" pseudo-register. If this pseudo-register contains a value >= 0 it is interpreted as the system call number that the kernel is supposed to restart. */