From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28857 invoked by alias); 11 Apr 2002 19:04:36 -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 28841 invoked from network); 11 Apr 2002 19:04:34 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 11 Apr 2002 19:04:34 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16vjsC-0003tm-00; Thu, 11 Apr 2002 15:04:44 -0400 Date: Thu, 11 Apr 2002 12:04:00 -0000 From: Daniel Jacobowitz To: gcc@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: .n suffixes for function names in stabs debug info (GCC 3.1-based compiler) Message-ID: <20020411150444.A14251@nevyn.them.org> Mail-Followup-To: gcc@gcc.gnu.org, gdb-patches@sources.redhat.com References: <20020411181942.H29472@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020411181942.H29472@act-europe.fr> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00421.txt.bz2 On Thu, Apr 11, 2002 at 06:19:42PM +0200, Joel Brobecker wrote: > The code that triggered this question was written in Ada but I > reproduced it using a small C program. This C example may seem a bit > unusual, but the root problem occurs quite often in usual situation when > writting code in Ada, for instance when using overloading, or nested > functions. > > Here is a small program: > << > int > main (void) > { > void inside (void) {} > return 0; > } > >> > > When compiled using the following command: > % gcc -gstabs+ -S hello.c > > GCC generates the following stabs for inside(): > << > .stabs "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0 > ^^ > || > >> > > This is happening on my x86-linux machine, but I suspect this to be > target independent. > > This ".0" suffix, which was not generated with GCC-2 backends, > is causing problems to GDB: I believe that GCC is wrong, but you are pointing at the wrong error. See below a bit. > > << > (gdb) b inside > Function "inside" not defined. > (gdb) b inside.0 <<---- Argh, need to give the name with the (right!) suffix > Breakpoint 1 at 0x8048579: file hello.c, line 4. > >> > > Do you think that GCC is right in putting these suffixes in the function > name? I see several options: > (1) GCC is not right, and the suffix should not be there, > GDB will be fine again > (2) GCC is right, and GDB should just strip these suffixes while > reading the stabs information. Disambiguation should be > done by other means (eg. a multiple choice question) > (3) GCC is right, and GDB should is right too. The C user need to > supply the full function name, including the suffix (not > appealing at all for the Ada users) > > The Stabs reference manual is not very acurate on this issue. The > example given in section "Nested procedures" seem to indicate that > (1) is the right answer: > .stabs "baz:f1,baz,bar",36,0,0,_baz.15 > But is not quite clear on this particular issue. > One side-effect of this approach is that the function name in the stabs > information becomes different from the name stored in the symbols table. > But should the name stored in the symbol table also contain this suffix? By "the stabs reference manual", I assume you mean the one included with GDB - yes, I see your example in it. That's not exactly a reference manual, unfortunately; it's essentially a whole lot of observations related to various stabs readers at the time. Sun actually publishes a reference manual to stabs, which looks almost nothing like the stabs that GCC put out. The one you're looking at says: For any of the symbol descriptors representing procedures, after the symbol descriptor and the type information is optionally a scope specifier. This consists of a comma, the name of the procedure, another comma, and the name of the enclosing procedure. The first name is local to the scope specified, and seems to be redundant with the name of the symbol (before the `:'). This feature is used by GCC, and presumably Pascal, Modula-2, etc., compilers, for nested functions. According to that, your example: > .stabs "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0 should be: > .stabs "inside.0:f(1,1)=(1,1),inside,main",36,0,4,inside.0 "The first name is local to the scope specified", as opposed to "the name of the symbol (before the `:')". GDB doesn't actually parse the scope information, and quite possibly never will, so this doesn't help you much. What happens in DWARF-2? For your information, Jim Blandy and others are working on greatly improving GDB's support for nested scopes right now; this may fall out of that, especially for the DWARF-2 case. All the rest of this is an aside; don't take it to seriously. GDB supports none of this. However, notice in the index of that manual; there are two references to the Nested Procedures chapters which describe 'I' and 'J', which don't appear in the manual. They appear to be an AIX extension. For curiousity's sake, I looked them up in Sun's document: "Stabs Interface Manual, Version 4.0 - February 1999". According to this document, the stabs should read roughly: .stabs "inside.0:J(1,1),inside,main", N_FUN, 0, 0, 0 .stabs "inside:W(1,1);inside.0;;;", N_LSYM, 0, 0, 0 (and various other sun stabs to get the arguments of the function and the location, etc.) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer