From: Daniel Jacobowitz <drow@mvista.com>
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)
Date: Thu, 11 Apr 2002 12:04:00 -0000 [thread overview]
Message-ID: <20020411150444.A14251@nevyn.them.org> (raw)
In-Reply-To: <20020411181942.H29472@act-europe.fr>
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
next prev parent reply other threads:[~2002-04-11 19:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-11 9:19 Joel Brobecker
2002-04-11 12:04 ` Daniel Jacobowitz [this message]
2002-04-12 1:28 ` Joel Brobecker
2002-04-12 1:43 ` Joel Brobecker
2002-04-12 7:34 ` Daniel Jacobowitz
2002-04-16 6:06 ` Daniel Berlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020411150444.A14251@nevyn.them.org \
--to=drow@mvista.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox