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

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

[Corinna Vinschen]

Hi,

I was debugging a situation, in which an C++ object file has been build
using v3 ABI, but GDB did not recognize it and was assuming v2 ABI.  The
target system is sh-elf, the compiler gcc 3.4.

What I found is this:

- The C++ ABI is set to v2 by default (gnu-v2-abi.c, _initialize_gnu_v2_abi).

- While reading symbols from the object file, at one point elf_symfile_read()
  (elfread.c) is called.

- elf_symfile_read() calls elf_symtab_read() which calls
  record_minimal_symbol() which calls prim_record_minimal_symbol_and_info().

- In prim_record_minimal_symbol_and_info(), the symbol language is set to
  language_auto unconditionally.

- After returning from elf_symtab_read(), install_minimal_symbols() is
  called.  At the end of install_minimal_symbols() a loop over all msymbols
  tries to figure out if v3 ABI is used.  This is done by requesting the
  demangeled name calling SYMBOL_DEMANGLED_NAME.

The problem is that SYMBOL_LANGUAGE is still set to language_auto and
the demangled name hasn't been generated at this point.

symbol_demangled_name() only returns the demangled name if the language is
set to a specific mangeling language and only if the demangeled name has
already been created.  This isn't the case at this point.  Ergo, the
v3 ABI isn't recognized and GDB wrongly assumes v2 ABI.

What's especially weird is the comment above install_minimal_symbols().
It implies that the function will try to demangle all symbols to set
the language correctly, but the function is not doing that.  It would
only recognize symbols which has already been demangeled but that just
don't happen.

I not sure if the below solution is entirely correct, but it solves
the problem in my case.  The solution is the create the demangled name
in the aforementioned loop in install_minimal_symbols().  This change
drops the FAIL count in the gdb.cp testsuite part from 54 to 6!


Corinna

	* minsyms.c (install_minimal_symbols): Create demangled names
	for all msymbol entries.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 10:55:25 -0000
@@ -924,6 +924,8 @@ install_minimal_symbols (struct objfile 
 	       mixing ABIs then the user will need to "set cp-abi"
 	       manually.  */
 	    const char *name = SYMBOL_LINKAGE_NAME (&objfile->msymbols[i]);
+	    SYMBOL_SET_NAMES (&objfile->msymbols[i], name, strlen (name),
+			      objfile);
 	    if (name[0] == '_' && name[1] == 'Z'
 		&& SYMBOL_DEMANGLED_NAME (&objfile->msymbols[i]) != NULL)
 	      {

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

Hi,

I was debugging a situation, in which an C++ object file has been build
using v3 ABI, but GDB did not recognize it and was assuming v2 ABI.  The
target system is sh-elf, the compiler gcc 3.4.

What I found is this:

- The C++ ABI is set to v2 by default (gnu-v2-abi.c, _initialize_gnu_v2_abi).

- While reading symbols from the object file, at one point elf_symfile_read()
  (elfread.c) is called.

- elf_symfile_read() calls elf_symtab_read() which calls
  record_minimal_symbol() which calls prim_record_minimal_symbol_and_info().

- In prim_record_minimal_symbol_and_info(), the symbol language is set to
  language_auto unconditionally.

- After returning from elf_symtab_read(), install_minimal_symbols() is
  called.  At the end of install_minimal_symbols() a loop over all msymbols
  tries to figure out if v3 ABI is used.  This is done by requesting the
  demangeled name calling SYMBOL_DEMANGLED_NAME.

The problem is that SYMBOL_LANGUAGE is still set to language_auto and
the demangled name hasn't been generated at this point.

symbol_demangled_name() only returns the demangled name if the language is
set to a specific mangeling language and only if the demangeled name has
already been created.  This isn't the case at this point.  Ergo, the
v3 ABI isn't recognized and GDB wrongly assumes v2 ABI.

What's especially weird is the comment above install_minimal_symbols().
It implies that the function will try to demangle all symbols to set
the language correctly, but the function is not doing that.  It would
only recognize symbols which has already been demangeled but that just
don't happen.

I not sure if the below solution is entirely correct, but it solves
the problem in my case.  The solution is the create the demangled name
in the aforementioned loop in install_minimal_symbols().  This change
drops the FAIL count in the gdb.cp testsuite part from 54 to 6!


Corinna

	* minsyms.c (install_minimal_symbols): Create demangled names
	for all msymbol entries.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 10:55:25 -0000
@@ -924,6 +924,8 @@ install_minimal_symbols (struct objfile 
 	       mixing ABIs then the user will need to "set cp-abi"
 	       manually.  */
 	    const char *name = SYMBOL_LINKAGE_NAME (&objfile->msymbols[i]);
+	    SYMBOL_SET_NAMES (&objfile->msymbols[i], name, strlen (name),
+			      objfile);
 	    if (name[0] == '_' && name[1] == 'Z'
 		&& SYMBOL_DEMANGLED_NAME (&objfile->msymbols[i]) != NULL)
 	      {

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 11:57:09AM +0100, Corinna Vinschen wrote:
> Hi,
> 
> I was debugging a situation, in which an C++ object file has been build
> using v3 ABI, but GDB did not recognize it and was assuming v2 ABI.  The
> target system is sh-elf, the compiler gcc 3.4.
> 
> What I found is this:
> 
> - The C++ ABI is set to v2 by default (gnu-v2-abi.c, _initialize_gnu_v2_abi).
> 
> - While reading symbols from the object file, at one point elf_symfile_read()
>   (elfread.c) is called.
> 
> - elf_symfile_read() calls elf_symtab_read() which calls
>   record_minimal_symbol() which calls prim_record_minimal_symbol_and_info().
> 
> - In prim_record_minimal_symbol_and_info(), the symbol language is set to
>   language_auto unconditionally.
> 
> - After returning from elf_symtab_read(), install_minimal_symbols() is
>   called.  At the end of install_minimal_symbols() a loop over all msymbols
>   tries to figure out if v3 ABI is used.  This is done by requesting the
>   demangeled name calling SYMBOL_DEMANGLED_NAME.
> 
> The problem is that SYMBOL_LANGUAGE is still set to language_auto and
> the demangled name hasn't been generated at this point.

This is absolutely not what should happen.

prim_record_minimal_symbol_and_info:
  SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);

symbol_set_names:
 ->  symbol_find_demangled_name
  if (gsymbol->language == language_cplus
      || gsymbol->language == language_auto)
    {
      demangled =
        cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
      if (demangled != NULL)
        {
          gsymbol->language = language_cplus;
          return demangled;
        }
    }

Please figure out why symbol_find_demangled_name has failed.  It sounds
to me like you are having a problem with leading underscores, if I
remember my sh-elf-foo correctly.

> What's especially weird is the comment above install_minimal_symbols().
> It implies that the function will try to demangle all symbols to set
> the language correctly, but the function is not doing that.  It would
> only recognize symbols which has already been demangeled but that just
> don't happen.

Comment is out of date.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 11:57:09AM +0100, Corinna Vinschen wrote:
> Hi,
> 
> I was debugging a situation, in which an C++ object file has been build
> using v3 ABI, but GDB did not recognize it and was assuming v2 ABI.  The
> target system is sh-elf, the compiler gcc 3.4.
> 
> What I found is this:
> 
> - The C++ ABI is set to v2 by default (gnu-v2-abi.c, _initialize_gnu_v2_abi).
> 
> - While reading symbols from the object file, at one point elf_symfile_read()
>   (elfread.c) is called.
> 
> - elf_symfile_read() calls elf_symtab_read() which calls
>   record_minimal_symbol() which calls prim_record_minimal_symbol_and_info().
> 
> - In prim_record_minimal_symbol_and_info(), the symbol language is set to
>   language_auto unconditionally.
> 
> - After returning from elf_symtab_read(), install_minimal_symbols() is
>   called.  At the end of install_minimal_symbols() a loop over all msymbols
>   tries to figure out if v3 ABI is used.  This is done by requesting the
>   demangeled name calling SYMBOL_DEMANGLED_NAME.
> 
> The problem is that SYMBOL_LANGUAGE is still set to language_auto and
> the demangled name hasn't been generated at this point.

This is absolutely not what should happen.

prim_record_minimal_symbol_and_info:
  SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);

symbol_set_names:
 ->  symbol_find_demangled_name
  if (gsymbol->language == language_cplus
      || gsymbol->language == language_auto)
    {
      demangled =
        cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
      if (demangled != NULL)
        {
          gsymbol->language = language_cplus;
          return demangled;
        }
    }

Please figure out why symbol_find_demangled_name has failed.  It sounds
to me like you are having a problem with leading underscores, if I
remember my sh-elf-foo correctly.

> What's especially weird is the comment above install_minimal_symbols().
> It implies that the function will try to demangle all symbols to set
> the language correctly, but the function is not doing that.  It would
> only recognize symbols which has already been demangeled but that just
> don't happen.

Comment is out of date.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

On Mar 10 10:08, Daniel Jacobowitz wrote:
> This is absolutely not what should happen.
> 
> prim_record_minimal_symbol_and_info:
>   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);

Oops.  I didn't see that.

> symbol_set_names:
>  ->  symbol_find_demangled_name
>   if (gsymbol->language == language_cplus
>       || gsymbol->language == language_auto)
>     {
>       demangled =
>         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
>       if (demangled != NULL)
>         {
>           gsymbol->language = language_cplus;
>           return demangled;
>         }
>     }
> 
> Please figure out why symbol_find_demangled_name has failed.  It sounds

It doesn't fail, at least not for the symbols which begin with "_Z".

> 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?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 04:54:50PM +0100, Corinna Vinschen wrote:
> On Mar 10 10:08, Daniel Jacobowitz wrote:
> > This is absolutely not what should happen.
> > 
> > prim_record_minimal_symbol_and_info:
> >   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
> 
> Oops.  I didn't see that.
> 
> > symbol_set_names:
> >  ->  symbol_find_demangled_name
> >   if (gsymbol->language == language_cplus
> >       || gsymbol->language == language_auto)
> >     {
> >       demangled =
> >         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
> >       if (demangled != NULL)
> >         {
> >           gsymbol->language = language_cplus;
> >           return demangled;
> >         }
> >     }
> > 
> > Please figure out why symbol_find_demangled_name has failed.  It sounds
> 
> It doesn't fail, at least not for the symbols which begin with "_Z".
> 
> > 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".

I'm not sure how we want to handle it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

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.

In install_minimal_symbols(), line 864ff is a loop, which strips the
first character from SYMBOL_LINKAGE_NAME, if that character equals
get_symbol_leading_char (objfile->obfd).  This leading_char is set
to "_".

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?!?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

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!

> In install_minimal_symbols(), line 864ff is a loop, which strips the
> first character from SYMBOL_LINKAGE_NAME, if that character equals
> get_symbol_leading_char (objfile->obfd).  This leading_char is set
> to "_".
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

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!

> In install_minimal_symbols(), line 864ff is a loop, which strips the
> first character from SYMBOL_LINKAGE_NAME, if that character equals
> get_symbol_leading_char (objfile->obfd).  This leading_char is set
> to "_".
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

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".

> > 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...


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

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".

> > 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...


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

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

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

[Corinna Vinschen]

On Mar 10 11:37, Daniel Jacobowitz wrote:
> What's the one symbol with just one underscore?

    _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

I have a revised patch to solve the GDB problem.  The leading_char
is removed right before the call to SYMBOL_SET_NAMES.  The same
functionality is removed from install_minimal_symbols entirely.
I tested on i686-pc-linux with gcc 3.3 and sh-elf with gcc 3.4.

The testsuite has 48 less FAILs on sh-elf, all in gdb.cp.

The testsuite has one FAIL more for i686-pc-linux:

  FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

though I must admit that I don't see what that has to do with my patch.


Corinna


	* minsyms.c (install_minimal_symbols): Move dropping leading
	char from linkage name from here...
	(prim_record_minimal_symbol_and_info): ...to here.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 17:17:37 -0000
@@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
   msymbol = &msym_bunch->contents[msym_bunch_index];
   SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
   SYMBOL_LANGUAGE (msymbol) = language_auto;
+  if (name[0] == get_symbol_leading_char (objfile->obfd))
+    ++name;
   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
 
   SYMBOL_VALUE_ADDRESS (msymbol) = address;
@@ -864,13 +866,7 @@ install_minimal_symbols (struct objfile 
       for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
 	{
 	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
-	    {
-	      msymbols[mcount] = bunch->contents[bindex];
-	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
-		{
-		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
-		}
-	    }
+	    msymbols[mcount] = bunch->contents[bindex];
 	  msym_bunch_index = BUNCH_SIZE;
 	}
 

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[David Carlton]

On Wed, 10 Mar 2004 18:54:46 +0100, Corinna Vinschen <vinschen@redhat.com> said:

> The testsuite has one FAIL more for i686-pc-linux:

>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

> though I must admit that I don't see what that has to do with my patch.

That fail happens to me all the time, and has nothing to do with your
patch.  So don't worry about it.

David Carlton
carlton@kealia.com

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

[David Carlton]

On Wed, 10 Mar 2004 18:54:46 +0100, Corinna Vinschen <vinschen@redhat.com> said:

> The testsuite has one FAIL more for i686-pc-linux:

>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

> though I must admit that I don't see what that has to do with my patch.

That fail happens to me all the time, and has nothing to do with your
patch.  So don't worry about it.

David Carlton
carlton@kealia.com

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

[Corinna Vinschen]

On Mar 10 18:54, Corinna Vinschen wrote:
> 	* minsyms.c (install_minimal_symbols): Move dropping leading
> 	char from linkage name from here...
> 	(prim_record_minimal_symbol_and_info): ...to here.

Corrected patch below.  I forgot to remove the now unused leading_char
from install_minimal_symbols.

Corinna


Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 18:20:36 -0000
@@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
   msymbol = &msym_bunch->contents[msym_bunch_index];
   SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
   SYMBOL_LANGUAGE (msymbol) = language_auto;
+  if (name[0] == get_symbol_leading_char (objfile->obfd))
+    ++name;
   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
 
   SYMBOL_VALUE_ADDRESS (msymbol) = address;
@@ -831,7 +833,6 @@ install_minimal_symbols (struct objfile 
   struct msym_bunch *bunch;
   struct minimal_symbol *msymbols;
   int alloc_count;
-  char leading_char;
 
   if (msym_count > 0)
     {
@@ -859,18 +860,11 @@ install_minimal_symbols (struct objfile 
          each bunch is full. */
 
       mcount = objfile->minimal_symbol_count;
-      leading_char = get_symbol_leading_char (objfile->obfd);
 
       for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
 	{
 	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
-	    {
-	      msymbols[mcount] = bunch->contents[bindex];
-	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
-		{
-		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
-		}
-	    }
+	    msymbols[mcount] = bunch->contents[bindex];
 	  msym_bunch_index = BUNCH_SIZE;
 	}
 

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

On Mar 10 18:54, Corinna Vinschen wrote:
> 	* minsyms.c (install_minimal_symbols): Move dropping leading
> 	char from linkage name from here...
> 	(prim_record_minimal_symbol_and_info): ...to here.

Corrected patch below.  I forgot to remove the now unused leading_char
from install_minimal_symbols.

Corinna


Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 18:20:36 -0000
@@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
   msymbol = &msym_bunch->contents[msym_bunch_index];
   SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
   SYMBOL_LANGUAGE (msymbol) = language_auto;
+  if (name[0] == get_symbol_leading_char (objfile->obfd))
+    ++name;
   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
 
   SYMBOL_VALUE_ADDRESS (msymbol) = address;
@@ -831,7 +833,6 @@ install_minimal_symbols (struct objfile 
   struct msym_bunch *bunch;
   struct minimal_symbol *msymbols;
   int alloc_count;
-  char leading_char;
 
   if (msym_count > 0)
     {
@@ -859,18 +860,11 @@ install_minimal_symbols (struct objfile 
          each bunch is full. */
 
       mcount = objfile->minimal_symbol_count;
-      leading_char = get_symbol_leading_char (objfile->obfd);
 
       for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
 	{
 	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
-	    {
-	      msymbols[mcount] = bunch->contents[bindex];
-	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
-		{
-		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
-		}
-	    }
+	    msymbols[mcount] = bunch->contents[bindex];
 	  msym_bunch_index = BUNCH_SIZE;
 	}
 

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

Hi,

could any symlink maintainer have a say on this?

Thanks,
Corinna

On Mar 10 19:22, Corinna Vinschen wrote:
> On Mar 10 18:54, Corinna Vinschen wrote:
> > 	* minsyms.c (install_minimal_symbols): Move dropping leading
> > 	char from linkage name from here...
> > 	(prim_record_minimal_symbol_and_info): ...to here.
> 
> Corrected patch below.  I forgot to remove the now unused leading_char
> from install_minimal_symbols.
> 
> Corinna
> 
> 
> Index: minsyms.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/minsyms.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 minsyms.c
> --- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
> +++ minsyms.c	10 Mar 2004 18:20:36 -0000
> @@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
>    msymbol = &msym_bunch->contents[msym_bunch_index];
>    SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
>    SYMBOL_LANGUAGE (msymbol) = language_auto;
> +  if (name[0] == get_symbol_leading_char (objfile->obfd))
> +    ++name;
>    SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
>  
>    SYMBOL_VALUE_ADDRESS (msymbol) = address;
> @@ -831,7 +833,6 @@ install_minimal_symbols (struct objfile 
>    struct msym_bunch *bunch;
>    struct minimal_symbol *msymbols;
>    int alloc_count;
> -  char leading_char;
>  
>    if (msym_count > 0)
>      {
> @@ -859,18 +860,11 @@ install_minimal_symbols (struct objfile 
>           each bunch is full. */
>  
>        mcount = objfile->minimal_symbol_count;
> -      leading_char = get_symbol_leading_char (objfile->obfd);
>  
>        for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
>  	{
>  	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
> -	    {
> -	      msymbols[mcount] = bunch->contents[bindex];
> -	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
> -		{
> -		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
> -		}
> -	    }
> +	    msymbols[mcount] = bunch->contents[bindex];
>  	  msym_bunch_index = BUNCH_SIZE;
>  	}

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

On Mar 22 18:34, Corinna Vinschen wrote:
> Hi,
> 
> could any symlink maintainer have a say on this?
            ^^^^^^^
	    sym*tab*

Sorry, I was apparently in the wrong movie,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Jim Blandy]

This looks good.

One comment: I notice that we actually remove the leading character
earlier in prim_record_minimal_symbol_and_info, to check if the name
is the same as that of the GCC compilation marker symbol.  It would be
nicer if we could just remove the leading character once, at the top
of the function, and then simplify the the "__gnu_compiled" test.
Doing so shouldn't interfere with the GCC_COMPILED_FLAG_SYMBOL tests,
since the code already presumes those both start with 'g'.

If that works, please commit.

Corinna Vinschen <vinschen@redhat.com> writes:

> On Mar 10 18:54, Corinna Vinschen wrote:
> > 	* minsyms.c (install_minimal_symbols): Move dropping leading
> > 	char from linkage name from here...
> > 	(prim_record_minimal_symbol_and_info): ...to here.
> 
> Corrected patch below.  I forgot to remove the now unused leading_char
> >From install_minimal_symbols.
> 
> Corinna
> 
> 
> Index: minsyms.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/minsyms.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 minsyms.c
> --- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
> +++ minsyms.c	10 Mar 2004 18:20:36 -0000
> @@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
>    msymbol = &msym_bunch->contents[msym_bunch_index];
>    SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
>    SYMBOL_LANGUAGE (msymbol) = language_auto;
> +  if (name[0] == get_symbol_leading_char (objfile->obfd))
> +    ++name;
>    SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
>  
>    SYMBOL_VALUE_ADDRESS (msymbol) = address;
> @@ -831,7 +833,6 @@ install_minimal_symbols (struct objfile 
>    struct msym_bunch *bunch;
>    struct minimal_symbol *msymbols;
>    int alloc_count;
> -  char leading_char;
>  
>    if (msym_count > 0)
>      {
> @@ -859,18 +860,11 @@ install_minimal_symbols (struct objfile 
>           each bunch is full. */
>  
>        mcount = objfile->minimal_symbol_count;
> -      leading_char = get_symbol_leading_char (objfile->obfd);
>  
>        for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
>  	{
>  	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
> -	    {
> -	      msymbols[mcount] = bunch->contents[bindex];
> -	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
> -		{
> -		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
> -		}
> -	    }
> +	    msymbols[mcount] = bunch->contents[bindex];
>  	  msym_bunch_index = BUNCH_SIZE;
>  	}
>  
> 
> -- 
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.

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

[Corinna Vinschen]

On Mar 25 15:44, Jim Blandy wrote:
> One comment: I notice that we actually remove the leading character
> earlier in prim_record_minimal_symbol_and_info, to check if the name
> is the same as that of the GCC compilation marker symbol.  It would be
> nicer if we could just remove the leading character once, at the top
> of the function, and then simplify the the "__gnu_compiled" test.
> Doing so shouldn't interfere with the GCC_COMPILED_FLAG_SYMBOL tests,
> since the code already presumes those both start with 'g'.

Well, it could interfere.  Assuming that leading char is the underscore.
The first test would now find "gcc_compiled.", but not "_gcc_compiled.".
When skipping the leading char before testing, the same test would now
also find "_gcc_compiled.".  If that's ok, I don't have a problem to
change it as you like.  Otherwise, I'd propose the below patch, which
avoids that problem.


Corinna

	* minsyms.c (install_minimal_symbols): Move dropping leading
	char from linkage name from here...
	(prim_record_minimal_symbol_and_info): ...to here.  Simplify
	test for "__gnu_compiled*" symbols.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	26 Mar 2004 11:28:46 -0000
@@ -580,26 +580,23 @@ prim_record_minimal_symbol_and_info (con
   struct msym_bunch *new;
   struct minimal_symbol *msymbol;
 
-  if (ms_type == mst_file_text)
-    {
-      /* Don't put gcc_compiled, __gnu_compiled_cplus, and friends into
-         the minimal symbols, because if there is also another symbol
-         at the same address (e.g. the first function of the file),
-         lookup_minimal_symbol_by_pc would have no way of getting the
-         right one.  */
-      if (name[0] == 'g'
-	  && (strcmp (name, GCC_COMPILED_FLAG_SYMBOL) == 0
-	      || strcmp (name, GCC2_COMPILED_FLAG_SYMBOL) == 0))
-	return (NULL);
-
-      {
-	const char *tempstring = name;
-	if (tempstring[0] == get_symbol_leading_char (objfile->obfd))
-	  ++tempstring;
-	if (strncmp (tempstring, "__gnu_compiled", 14) == 0)
-	  return (NULL);
-      }
-    }
+  /* Don't put gcc_compiled, __gnu_compiled_cplus, and friends into
+     the minimal symbols, because if there is also another symbol
+     at the same address (e.g. the first function of the file),
+     lookup_minimal_symbol_by_pc would have no way of getting the
+     right one.  */
+  if (ms_type == mst_file_text && name[0] == 'g'
+      && (strcmp (name, GCC_COMPILED_FLAG_SYMBOL) == 0
+	  || strcmp (name, GCC2_COMPILED_FLAG_SYMBOL) == 0))
+    return (NULL);
+
+  /* It's save to strip the leading char here once, since the name
+     is also stored stripped in the minimal symbol table. */
+  if (name[0] == get_symbol_leading_char (objfile->obfd))
+    ++name;
+
+  if (ms_type == mst_file_text && strncmp (name, "__gnu_compiled", 14) == 0)
+    return (NULL);
 
   if (msym_bunch_index == BUNCH_SIZE)
     {
@@ -831,7 +828,6 @@ install_minimal_symbols (struct objfile 
   struct msym_bunch *bunch;
   struct minimal_symbol *msymbols;
   int alloc_count;
-  char leading_char;
 
   if (msym_count > 0)
     {
@@ -859,18 +855,11 @@ install_minimal_symbols (struct objfile 
          each bunch is full. */
 
       mcount = objfile->minimal_symbol_count;
-      leading_char = get_symbol_leading_char (objfile->obfd);
 
       for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
 	{
 	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
-	    {
-	      msymbols[mcount] = bunch->contents[bindex];
-	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
-		{
-		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
-		}
-	    }
+	    msymbols[mcount] = bunch->contents[bindex];
 	  msym_bunch_index = BUNCH_SIZE;
 	}
 


-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Eli Zaretskii]

> Date: Fri, 26 Mar 2004 12:39:29 +0100
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> +  /* It's save to strip the leading char here once, since the name
             ^^^^
A typo.

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

[Jim Blandy]

Corinna Vinschen <vinschen@redhat.com> writes:
> On Mar 25 15:44, Jim Blandy wrote:
> > One comment: I notice that we actually remove the leading character
> > earlier in prim_record_minimal_symbol_and_info, to check if the name
> > is the same as that of the GCC compilation marker symbol.  It would be
> > nicer if we could just remove the leading character once, at the top
> > of the function, and then simplify the the "__gnu_compiled" test.
> > Doing so shouldn't interfere with the GCC_COMPILED_FLAG_SYMBOL tests,
> > since the code already presumes those both start with 'g'.
> 
> Well, it could interfere.  Assuming that leading char is the underscore.
> The first test would now find "gcc_compiled.", but not "_gcc_compiled.".
> When skipping the leading char before testing, the same test would now
> also find "_gcc_compiled.".  If that's ok, I don't have a problem to
> change it as you like.  Otherwise, I'd propose the below patch, which
> avoids that problem.

Sure, this looks good; it leaves the current behavior unchanged.
Please commit.

I'm kind of amazed that some of the GCC compilation symbols get
prefixed, while others don't.  That exact arrangement --- where
GCC_COMPILED_FLAG_SYMBOL and GCC2_COMPILED_FLAG_SYMBOL are tested
before stripping the leading char, and __gnu_compiled is tested after
stripping --- originated in 1993 in dbxread.c, and was later moved to
minsyms.c:

Wed Jul 28 13:19:34 1993  Jim Kingdon  (kingdon@lioth.cygnus.com)

	* config/mips/xm-mips.h: Define HAVE_TERMIOS.

	* dbxread.c (record_minimal_symbol): Don't put gcc_compiled or
	__gnu_compiled* symbols into the minimal symbols.

(dbxread.c 1.153 in the internal Red Hat repository).  There's no
indication of why the distinction is made.  But it does seem to have
been done deliberately, rather than being the unintentional result of
accreted changes.  So I guess we should leave it as is.  I'll stick a
note in there after you've committed.

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

[Corinna Vinschen]

On Mar 28 13:28, Jim Blandy wrote:
> Corinna Vinschen <vinschen@redhat.com> writes:
> > Well, it could interfere.  Assuming that leading char is the underscore.
> > The first test would now find "gcc_compiled.", but not "_gcc_compiled.".
> > When skipping the leading char before testing, the same test would now
> > also find "_gcc_compiled.".  If that's ok, I don't have a problem to
> > change it as you like.  Otherwise, I'd propose the below patch, which
> > avoids that problem.
> 
> Sure, this looks good; it leaves the current behavior unchanged.
> Please commit.

Thanks, applied.  I've also fixed the typo Eli found.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Ian Lance Taylor]

Corinna Vinschen <vinschen@redhat.com> writes:

> On Mar 10 11:37, Daniel Jacobowitz wrote:
> > What's the one symbol with just one underscore?
> 
>     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

That should be investigated further, as it probably indicates a gcc
bug.

Consider this source code:

void __verbose_terminate_handler()
{
  static int terminating = 0;
  if (terminating)
    {
      return;
    }
  terminating = 1;
}

If you compile it as a C file, do you see the initial underscore on
"terminating".  If you compile it as a C++ file, do you see two
initial underscores before the 'Z'?  It should be consistent.

Ian

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

[Ian Lance Taylor]

Corinna Vinschen <vinschen@redhat.com> writes:

> On Mar 10 11:37, Daniel Jacobowitz wrote:
> > What's the one symbol with just one underscore?
> 
>     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

That should be investigated further, as it probably indicates a gcc
bug.

Consider this source code:

void __verbose_terminate_handler()
{
  static int terminating = 0;
  if (terminating)
    {
      return;
    }
  terminating = 1;
}

If you compile it as a C file, do you see the initial underscore on
"terminating".  If you compile it as a C++ file, do you see two
initial underscores before the 'Z'?  It should be consistent.

Ian

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

[Corinna Vinschen]

On Mar 10 13:30, Ian Lance Taylor wrote:
> Corinna Vinschen <vinschen@redhat.com> writes:
> 
> > On Mar 10 11:37, Daniel Jacobowitz wrote:
> > > What's the one symbol with just one underscore?
> > 
> >     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating
> 
> That should be investigated further, as it probably indicates a gcc
> bug.
> 
> Consider this source code:
> 
> void __verbose_terminate_handler()
> {
>   static int terminating = 0;
>   if (terminating)
>     {
>       return;
>     }
>   terminating = 1;
> }
> 
> If you compile it as a C file, do you see the initial underscore on
> "terminating".  If you compile it as a C++ file, do you see two
> initial underscores before the 'Z'?  It should be consistent.

It seems to be consistent:

  $ nm x.c.o 
  00000000 T ___verbose_terminate_handler
  00000000 b terminating.0

  $ nm x.cc.o
  00000000 b _ZZ27__verbose_terminate_handlervE11terminating
  00000000 T __Z27__verbose_terminate_handlerv

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

On Mar 10 13:30, Ian Lance Taylor wrote:
> Corinna Vinschen <vinschen@redhat.com> writes:
> 
> > On Mar 10 11:37, Daniel Jacobowitz wrote:
> > > What's the one symbol with just one underscore?
> > 
> >     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating
> 
> That should be investigated further, as it probably indicates a gcc
> bug.
> 
> Consider this source code:
> 
> void __verbose_terminate_handler()
> {
>   static int terminating = 0;
>   if (terminating)
>     {
>       return;
>     }
>   terminating = 1;
> }
> 
> If you compile it as a C file, do you see the initial underscore on
> "terminating".  If you compile it as a C++ file, do you see two
> initial underscores before the 'Z'?  It should be consistent.

It seems to be consistent:

  $ nm x.c.o 
  00000000 T ___verbose_terminate_handler
  00000000 b terminating.0

  $ nm x.cc.o
  00000000 b _ZZ27__verbose_terminate_handlervE11terminating
  00000000 T __Z27__verbose_terminate_handlerv

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Ian Lance Taylor]

Corinna Vinschen <vinschen@redhat.com> writes:

> > Consider this source code:
> > 
> > void __verbose_terminate_handler()
> > {
> >   static int terminating = 0;
> >   if (terminating)
> >     {
> >       return;
> >     }
> >   terminating = 1;
> > }
> > 
> > If you compile it as a C file, do you see the initial underscore on
> > "terminating".  If you compile it as a C++ file, do you see two
> > initial underscores before the 'Z'?  It should be consistent.
> 
> It seems to be consistent:
> 
>   $ nm x.c.o 
>   00000000 T ___verbose_terminate_handler
>   00000000 b terminating.0
> 
>   $ nm x.cc.o
>   00000000 b _ZZ27__verbose_terminate_handlervE11terminating
>   00000000 T __Z27__verbose_terminate_handlerv

Unfortunately, it seems to be consistently wrong.

I think this is a gcc bug.  The symbol prefix should be applied
consistently to symbols whether they are globally or locally visible.
I don't see just where it is happening, though.

Ian

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

[Ian Lance Taylor]

Corinna Vinschen <vinschen@redhat.com> writes:

> > Consider this source code:
> > 
> > void __verbose_terminate_handler()
> > {
> >   static int terminating = 0;
> >   if (terminating)
> >     {
> >       return;
> >     }
> >   terminating = 1;
> > }
> > 
> > If you compile it as a C file, do you see the initial underscore on
> > "terminating".  If you compile it as a C++ file, do you see two
> > initial underscores before the 'Z'?  It should be consistent.
> 
> It seems to be consistent:
> 
>   $ nm x.c.o 
>   00000000 T ___verbose_terminate_handler
>   00000000 b terminating.0
> 
>   $ nm x.cc.o
>   00000000 b _ZZ27__verbose_terminate_handlervE11terminating
>   00000000 T __Z27__verbose_terminate_handlerv

Unfortunately, it seems to be consistently wrong.

I think this is a gcc bug.  The symbol prefix should be applied
consistently to symbols whether they are globally or locally visible.
I don't see just where it is happening, though.

Ian

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

[Corinna Vinschen]

On Mar 10 11:37, Daniel Jacobowitz wrote:
> What's the one symbol with just one underscore?

    _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

I have a revised patch to solve the GDB problem.  The leading_char
is removed right before the call to SYMBOL_SET_NAMES.  The same
functionality is removed from install_minimal_symbols entirely.
I tested on i686-pc-linux with gcc 3.3 and sh-elf with gcc 3.4.

The testsuite has 48 less FAILs on sh-elf, all in gdb.cp.

The testsuite has one FAIL more for i686-pc-linux:

  FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

though I must admit that I don't see what that has to do with my patch.


Corinna


	* minsyms.c (install_minimal_symbols): Move dropping leading
	char from linkage name from here...
	(prim_record_minimal_symbol_and_info): ...to here.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.41
diff -u -p -r1.41 minsyms.c
--- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
+++ minsyms.c	10 Mar 2004 17:17:37 -0000
@@ -611,6 +611,8 @@ prim_record_minimal_symbol_and_info (con
   msymbol = &msym_bunch->contents[msym_bunch_index];
   SYMBOL_INIT_LANGUAGE_SPECIFIC (msymbol, language_unknown);
   SYMBOL_LANGUAGE (msymbol) = language_auto;
+  if (name[0] == get_symbol_leading_char (objfile->obfd))
+    ++name;
   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
 
   SYMBOL_VALUE_ADDRESS (msymbol) = address;
@@ -864,13 +866,7 @@ install_minimal_symbols (struct objfile 
       for (bunch = msym_bunch; bunch != NULL; bunch = bunch->next)
 	{
 	  for (bindex = 0; bindex < msym_bunch_index; bindex++, mcount++)
-	    {
-	      msymbols[mcount] = bunch->contents[bindex];
-	      if (SYMBOL_LINKAGE_NAME (&msymbols[mcount])[0] == leading_char)
-		{
-		  SYMBOL_LINKAGE_NAME (&msymbols[mcount])++;
-		}
-	    }
+	    msymbols[mcount] = bunch->contents[bindex];
 	  msym_bunch_index = BUNCH_SIZE;
 	}
 

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 06:54:46PM +0100, Corinna Vinschen wrote:
> On Mar 10 11:37, Daniel Jacobowitz wrote:
> > What's the one symbol with just one underscore?
> 
>     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

I can't see any reason for that to be special-cased, so this may be a
GCC bug.

> I have a revised patch to solve the GDB problem.  The leading_char
> is removed right before the call to SYMBOL_SET_NAMES.  The same
> functionality is removed from install_minimal_symbols entirely.
> I tested on i686-pc-linux with gcc 3.3 and sh-elf with gcc 3.4.
> 
> The testsuite has 48 less FAILs on sh-elf, all in gdb.cp.
> 
> The testsuite has one FAIL more for i686-pc-linux:
> 
>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
> 
> though I must admit that I don't see what that has to do with my patch.
> 
> 
> Corinna
> 
> 
> 	* minsyms.c (install_minimal_symbols): Move dropping leading
> 	char from linkage name from here...
> 	(prim_record_minimal_symbol_and_info): ...to here.

Thanks.  I recommend this patch for symtab approval.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 06:54:46PM +0100, Corinna Vinschen wrote:
> On Mar 10 11:37, Daniel Jacobowitz wrote:
> > What's the one symbol with just one underscore?
> 
>     _ZZN9__gnu_cxx27__verbose_terminate_handlerEvE11terminating

I can't see any reason for that to be special-cased, so this may be a
GCC bug.

> I have a revised patch to solve the GDB problem.  The leading_char
> is removed right before the call to SYMBOL_SET_NAMES.  The same
> functionality is removed from install_minimal_symbols entirely.
> I tested on i686-pc-linux with gcc 3.3 and sh-elf with gcc 3.4.
> 
> The testsuite has 48 less FAILs on sh-elf, all in gdb.cp.
> 
> The testsuite has one FAIL more for i686-pc-linux:
> 
>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
> 
> though I must admit that I don't see what that has to do with my patch.
> 
> 
> Corinna
> 
> 
> 	* minsyms.c (install_minimal_symbols): Move dropping leading
> 	char from linkage name from here...
> 	(prim_record_minimal_symbol_and_info): ...to here.

Thanks.  I recommend this patch for symtab approval.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

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

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

[Corinna Vinschen]

On Mar 10 17:34, Corinna Vinschen wrote:
> On Mar 10 11:20, Daniel Jacobowitz wrote:
> > 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...

Wait a second.  If the symbols actually begin with _Z as they do e.g. on
Linux, then the test we're talking about would fail on Linx, too, if...
yes, if leading_char would be "_" on Linux as well.  But on Linux the
leading_char is \0.

So, it looks like the actual problem is, that SYMBOL_SET_NAMES is
called in prim_record_minimal_symbol_and_info, without having stripped
the leading_char from the symbol names.

That doesn't explain why there's one symbol which has no leading _
but that would make sense for all other mangled symbols given in the
object file, right?


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 05:43:35PM +0100, Corinna Vinschen wrote:
> On Mar 10 17:34, Corinna Vinschen wrote:
> > On Mar 10 11:20, Daniel Jacobowitz wrote:
> > > 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...
> 
> Wait a second.  If the symbols actually begin with _Z as they do e.g. on
> Linux, then the test we're talking about would fail on Linx, too, if...
> yes, if leading_char would be "_" on Linux as well.  But on Linux the
> leading_char is \0.
> 
> So, it looks like the actual problem is, that SYMBOL_SET_NAMES is
> called in prim_record_minimal_symbol_and_info, without having stripped
> the leading_char from the symbol names.

Right.  I think that this has been a problem for a long time, but
I made it worse somehow with the introduction of SYMBOL_SET_NAMES.

> That doesn't explain why there's one symbol which has no leading _
> but that would make sense for all other mangled symbols given in the
> object file, right?

Precisely.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 05:43:35PM +0100, Corinna Vinschen wrote:
> On Mar 10 17:34, Corinna Vinschen wrote:
> > On Mar 10 11:20, Daniel Jacobowitz wrote:
> > > 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...
> 
> Wait a second.  If the symbols actually begin with _Z as they do e.g. on
> Linux, then the test we're talking about would fail on Linx, too, if...
> yes, if leading_char would be "_" on Linux as well.  But on Linux the
> leading_char is \0.
> 
> So, it looks like the actual problem is, that SYMBOL_SET_NAMES is
> called in prim_record_minimal_symbol_and_info, without having stripped
> the leading_char from the symbol names.

Right.  I think that this has been a problem for a long time, but
I made it worse somehow with the introduction of SYMBOL_SET_NAMES.

> That doesn't explain why there's one symbol which has no leading _
> but that would make sense for all other mangled symbols given in the
> object file, right?

Precisely.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

On Mar 10 17:34, Corinna Vinschen wrote:
> On Mar 10 11:20, Daniel Jacobowitz wrote:
> > 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...

Wait a second.  If the symbols actually begin with _Z as they do e.g. on
Linux, then the test we're talking about would fail on Linx, too, if...
yes, if leading_char would be "_" on Linux as well.  But on Linux the
leading_char is \0.

So, it looks like the actual problem is, that SYMBOL_SET_NAMES is
called in prim_record_minimal_symbol_and_info, without having stripped
the leading_char from the symbol names.

That doesn't explain why there's one symbol which has no leading _
but that would make sense for all other mangled symbols given in the
object file, right?


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Corinna Vinschen]

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.

In install_minimal_symbols(), line 864ff is a loop, which strips the
first character from SYMBOL_LINKAGE_NAME, if that character equals
get_symbol_leading_char (objfile->obfd).  This leading_char is set
to "_".

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?!?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Daniel Jacobowitz]

On Wed, Mar 10, 2004 at 04:54:50PM +0100, Corinna Vinschen wrote:
> On Mar 10 10:08, Daniel Jacobowitz wrote:
> > This is absolutely not what should happen.
> > 
> > prim_record_minimal_symbol_and_info:
> >   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);
> 
> Oops.  I didn't see that.
> 
> > symbol_set_names:
> >  ->  symbol_find_demangled_name
> >   if (gsymbol->language == language_cplus
> >       || gsymbol->language == language_auto)
> >     {
> >       demangled =
> >         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
> >       if (demangled != NULL)
> >         {
> >           gsymbol->language = language_cplus;
> >           return demangled;
> >         }
> >     }
> > 
> > Please figure out why symbol_find_demangled_name has failed.  It sounds
> 
> It doesn't fail, at least not for the symbols which begin with "_Z".
> 
> > 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".

I'm not sure how we want to handle it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

On Mar 10 10:08, Daniel Jacobowitz wrote:
> This is absolutely not what should happen.
> 
> prim_record_minimal_symbol_and_info:
>   SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile);

Oops.  I didn't see that.

> symbol_set_names:
>  ->  symbol_find_demangled_name
>   if (gsymbol->language == language_cplus
>       || gsymbol->language == language_auto)
>     {
>       demangled =
>         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
>       if (demangled != NULL)
>         {
>           gsymbol->language = language_cplus;
>           return demangled;
>         }
>     }
> 
> Please figure out why symbol_find_demangled_name has failed.  It sounds

It doesn't fail, at least not for the symbols which begin with "_Z".

> 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?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Jim Blandy]

Corinna Vinschen <vinschen@redhat.com> writes:
> Corinna
> 
> 	* minsyms.c (install_minimal_symbols): Create demangled names
> 	for all msymbol entries.
> 
> Index: minsyms.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/minsyms.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 minsyms.c
> --- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
> +++ minsyms.c	10 Mar 2004 10:55:25 -0000
> @@ -924,6 +924,8 @@ install_minimal_symbols (struct objfile 
>  	       mixing ABIs then the user will need to "set cp-abi"
>  	       manually.  */
>  	    const char *name = SYMBOL_LINKAGE_NAME (&objfile->msymbols[i]);
> +	    SYMBOL_SET_NAMES (&objfile->msymbols[i], name, strlen (name),
> +			      objfile);
>  	    if (name[0] == '_' && name[1] == 'Z'
>  		&& SYMBOL_DEMANGLED_NAME (&objfile->msymbols[i]) != NULL)
>  	      {

It would be nice to get the C++ guys' opinion of this, but it's my
understanding that demangling all symbols contributes a substantial
amount of time to the startup, and can consume very large amounts of
memory when debugging large C++ programs.

If you were to move the use of SYMBOL_SET_NAMES inside the if, after
the check for the "_Z" prefix but (obviously) before the use of
SYMBOL_DEMANGLED_NAME, then we'd only try to demangle
suspicious-looking names, and we'd stop after successfully demangling
at most one.

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

[Jim Blandy]

Corinna Vinschen <vinschen@redhat.com> writes:
> Corinna
> 
> 	* minsyms.c (install_minimal_symbols): Create demangled names
> 	for all msymbol entries.
> 
> Index: minsyms.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/minsyms.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 minsyms.c
> --- minsyms.c	9 Feb 2004 19:13:46 -0000	1.41
> +++ minsyms.c	10 Mar 2004 10:55:25 -0000
> @@ -924,6 +924,8 @@ install_minimal_symbols (struct objfile 
>  	       mixing ABIs then the user will need to "set cp-abi"
>  	       manually.  */
>  	    const char *name = SYMBOL_LINKAGE_NAME (&objfile->msymbols[i]);
> +	    SYMBOL_SET_NAMES (&objfile->msymbols[i], name, strlen (name),
> +			      objfile);
>  	    if (name[0] == '_' && name[1] == 'Z'
>  		&& SYMBOL_DEMANGLED_NAME (&objfile->msymbols[i]) != NULL)
>  	      {

It would be nice to get the C++ guys' opinion of this, but it's my
understanding that demangling all symbols contributes a substantial
amount of time to the startup, and can consume very large amounts of
memory when debugging large C++ programs.

If you were to move the use of SYMBOL_SET_NAMES inside the if, after
the check for the "_Z" prefix but (obviously) before the use of
SYMBOL_DEMANGLED_NAME, then we'd only try to demangle
suspicious-looking names, and we'd stop after successfully demangling
at most one.

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

[Michael Elizabeth Chastain]

>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

That's not a problem.  The results for this test are unstable --
the results can change from run to run, on an identical system.

This test script puts gdb into annotation mode and then does a bunch of
things, including sending a ^C and checking that gdb responds properly.
gdb is flaky in that area; I think it's some sort of signal-handling
race with respect to printing the prompt.  PR gdb/544 has more
information on this.

Michael C

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

[Michael Elizabeth Chastain]

>   FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)

That's not a problem.  The results for this test are unstable --
the results can change from run to run, on an identical system.

This test script puts gdb into annotation mode and then does a bunch of
things, including sending a ^C and checking that gdb responds properly.
gdb is flaky in that area; I think it's some sort of signal-handling
race with respect to printing the prompt.  PR gdb/544 has more
information on this.

Michael C