Re: [RFA] minsyms.c: Fix switching to GNU v3 ABI

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 10, 2004 at 05:34:16PM +0100, Corinna Vinschen wrote:
> On Mar 10 11:20, Daniel Jacobowitz wrote:
> > On Wed, Mar 10, 2004 at 05:16:17PM +0100, Corinna Vinschen wrote:
> > > On Mar 10 11:04, Daniel Jacobowitz wrote:
> > > > > > to me like you are having a problem with leading underscores, if I
> > > > > > remember my sh-elf-foo correctly.
> > > > > 
> > > > > Could you tell more about that?  I see a big bunch of symbols beginning
> > > > > with "__Z".  Is that what you mean?
> > > > 
> > > > Yes, precisely.  On sh-elf all symbols are prefixed with an underscore. 
> > > > I've been curious for a while about where, precisely, the leading
> > > > underscore is supposed to get stripped before we demangle; apparently,
> > > > the answer is "not early enough".
> > > 
> > > Ok, I think I see now what happens.
> > > 
> > > There are symbols beginning with "_Z" and (the most) beginning with "__Z".
> > > 
> > > The symbols beginning with "_Z" are correctly recognized as language_cplus.
> > > 
> > > The symbols beginning with "__Z" are still language_auto after
> > > prim_record_minimal_symbol_and_info has been called, since the demangler
> > > in libiberty doesn't recognize them.
> > 
> > Wait a sec, why is that happening?  Either everything should have a
> > leading _ or nothing should!
> 
> I'm not sure if I understand the question.  All symbols have leading
> underscores, some (actually just one!) have one underscore, all others
> have two underscores.  I have no idea why that happens, it's what gcc
> 3.4 generates, I guess.
> 
> I checked the C++ demangler in libiberty again and it requires that
> the symbols begin with "_Z", not with "__Z".

On targets which prefix symbols with an underscore, it's GDB's
responsibility to strip the underscore before trying to demangle it.
C++ demangled names start with '_Z' - that's after stripping.
What's the one symbol with just one underscore?

> > > So, after this loop SYMBOL_LINKAGE_NAME begins with "Z" for the first
> > > set of symbols (which *are* recognized as cplus variables) and with
> > > "_Z" for the second set of symbols (which are still auto).  But now
> > > SYMBOL_DEMANGLED_NAME is only called for the second set of symbols
> > > and SYMBOL_DEMANGLED_NAME returns NULL for those symbols.
> > > 
> > > What can we do?!?
> > 
> > Move the check earlier?  It should not be necessary to change
> > SYMBOL_LINKAGE_NAME.  I think you could do this in
> > prim_record_minimal_symbol_and_info at the call site of
> > SYMBOL_SET_NAMES.
> 
> I'm more and more under the impression that the problem is raised due
> to a bug in the symbol generation in gcc.  It doesn't seem worth to
> change GDB proactively...

I think, if there's a bug, it's the other way round - that one oddball
symbol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer