gnu-v3-abi.c: problems w/ virtual base class

gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

Hello,

We're porting gdb 5.2.1 to our toolchain and I'm noticing a problem with
inherited virtual base classes.

Given:

class vA {
public:
int va;
int vx;
};

class vB : public virtual vA {
public:
int vb;
int vx;
};

vB g_vB;

we get the failure:

Expected output:
(gdb) print g_vB
$73 = {<vA> = {va = 3, vx = 4}, _vb$vA = 0x80422a4, vb = 5, vx = 6}
(gdb)

Output given:
(gdb) print g_vB
$67 = {Expected a negative vbase offset (old compiler?)
(gdb)

Now I looked at the comment for this in gnu-v3-abi.c and I'm guessing the
issue has to do with the fact that we're using gcc-2.95.3.  I'm thinking
that, because this worked with gdb-5.0, it's probably a configuration error
in how we build gdb.  Can anyone tell me anything about the c++ abi stuff
and if there's any way to make it play nicely with an older gcc?

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 12:10:26PM -0500, Kris Warkentin wrote:
> Hello,
> 
> We're porting gdb 5.2.1 to our toolchain and I'm noticing a problem with
> inherited virtual base classes.
> 
> Given:
> 
> class vA {
> public:
> int va;
> int vx;
> };
> 
> class vB : public virtual vA {
> public:
> int vb;
> int vx;
> };
> 
> vB g_vB;
> 
> we get the failure:
> 
> Expected output:
> (gdb) print g_vB
> $73 = {<vA> = {va = 3, vx = 4}, _vb$vA = 0x80422a4, vb = 5, vx = 6}
> (gdb)
> 
> Output given:
> (gdb) print g_vB
> $67 = {Expected a negative vbase offset (old compiler?)
> (gdb)
> 
> Now I looked at the comment for this in gnu-v3-abi.c and I'm guessing the
> issue has to do with the fact that we're using gcc-2.95.3.  I'm thinking
> that, because this worked with gdb-5.0, it's probably a configuration error
> in how we build gdb.  Can anyone tell me anything about the c++ abi stuff
> and if there's any way to make it play nicely with an older gcc?

Well, why do you have it using the gnu-v3 code?  You've got a patently
gnu-v2 compiler.

Please don't tell me QNX has a symbol starting with _Z in normal
binaries... that would fool the autodetection code.  I think Free
Pascal has a similar problem, since it starts all symbols with
underscores.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

> Well, why do you have it using the gnu-v3 code?  You've got a patently
> gnu-v2 compiler.

I wasn't aware that I had it using anything in particular - we just moved
our 5.0 support forward and got it running but now we're discovering some of
these gotcha's

> Please don't tell me QNX has a symbol starting with _Z in normal
> binaries... that would fool the autodetection code.  I think Free
> Pascal has a similar problem, since it starts all symbols with
> underscores.

objdump -x foo | grep _Z gave me nothing.  You say there's an autodetect
routine?  I'll have to look at it to see why it thinks we're gnu-v3 I
suppose.

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 12:30:12PM -0500, Kris Warkentin wrote:
> > Well, why do you have it using the gnu-v3 code?  You've got a patently
> > gnu-v2 compiler.
> 
> I wasn't aware that I had it using anything in particular - we just moved
> our 5.0 support forward and got it running but now we're discovering some of
> these gotcha's
> 
> > Please don't tell me QNX has a symbol starting with _Z in normal
> > binaries... that would fool the autodetection code.  I think Free
> > Pascal has a similar problem, since it starts all symbols with
> > underscores.
> 
> objdump -x foo | grep _Z gave me nothing.  You say there's an autodetect
> routine?  I'll have to look at it to see why it thinks we're gnu-v3 I
> suppose.

It's in minsyms.c:install_minimal_symbols.  Hmm, does a breakpoint on
switch_to_cp_abi turn up anything?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

> > objdump -x foo | grep _Z gave me nothing.  You say there's an autodetect
> > routine?  I'll have to look at it to see why it thinks we're gnu-v3 I
> > suppose.
>
> It's in minsyms.c:install_minimal_symbols.  Hmm, does a breakpoint on
> switch_to_cp_abi turn up anything?

Odd.  According to that, it switched to gnu-v2.  And it worked properly.
What the heck is going on here?  I just reproduced this from the PR about 2
minutes ago and now I'm not seeing it. AAARGH!!!

Sorry Daniel.  I'm obviously losing my mind here so now I have to go back
and reproduce it again. *sigh*

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

> > > objdump -x foo | grep _Z gave me nothing.  You say there's an
autodetect
> > > routine?  I'll have to look at it to see why it thinks we're gnu-v3 I
> > > suppose.
> >
> > It's in minsyms.c:install_minimal_symbols.  Hmm, does a breakpoint on
> > switch_to_cp_abi turn up anything?
>
> Odd.  According to that, it switched to gnu-v2.  And it worked properly.
> What the heck is going on here?  I just reproduced this from the PR about
2
> minutes ago and now I'm not seeing it. AAARGH!!!
>
> Sorry Daniel.  I'm obviously losing my mind here so now I have to go back
> and reproduce it again. *sigh*

Okay, I'm seeing it in the Neutrino hosted gdb, not Windows hosted.  That's
the problem with 4 hosts and 5 targets...:-P

I found the naughtiness.  auto_solib_add is true on Neutrino but not on
Windows.  Guess who defines _Zero in their libc?  We do!!

Doh.

Thanks for the help.

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

> I found the naughtiness.  auto_solib_add is true on Neutrino but not on
> Windows.  Guess who defines _Zero in their libc?  We do!!
>

Actually Daniel, before I let you go, can you offer any suggestions on how
to resolve this?  The part of our libc that defines _Zero is third party
(Dinkum) and we're not super keen on monkeying with it.  What is the
rationale for using a symbol starting with _Z as an autodetection for
v3-abi?  Are there some symbols defined by gcc-3.x that start with _Z?  I'm
just wondering if there might be some better way of dealing with this -
perhaps have a special note in gnu-v3 binaries.  This could be handy for
linkers as well for resolving library versionitus.

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 01:48:37PM -0500, Kris Warkentin wrote:
> > > > objdump -x foo | grep _Z gave me nothing.  You say there's an
> autodetect
> > > > routine?  I'll have to look at it to see why it thinks we're gnu-v3 I
> > > > suppose.
> > >
> > > It's in minsyms.c:install_minimal_symbols.  Hmm, does a breakpoint on
> > > switch_to_cp_abi turn up anything?
> >
> > Odd.  According to that, it switched to gnu-v2.  And it worked properly.
> > What the heck is going on here?  I just reproduced this from the PR about
> 2
> > minutes ago and now I'm not seeing it. AAARGH!!!
> >
> > Sorry Daniel.  I'm obviously losing my mind here so now I have to go back
> > and reproduce it again. *sigh*
> 
> Okay, I'm seeing it in the Neutrino hosted gdb, not Windows hosted.  That's
> the problem with 4 hosts and 5 targets...:-P
> 
> I found the naughtiness.  auto_solib_add is true on Neutrino but not on
> Windows.  Guess who defines _Zero in their libc?  We do!!
> 
> Doh.
> 
> Thanks for the help.

OK, that's the problem.  What we should probably be doing in minsyms.c
is checking for a valid v3 mangled name...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gnu-v3-abi.c: problems w/ virtual base class

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 02:00:02PM -0500, Kris Warkentin wrote:
> > I found the naughtiness.  auto_solib_add is true on Neutrino but not on
> > Windows.  Guess who defines _Zero in their libc?  We do!!
> >
> 
> Actually Daniel, before I let you go, can you offer any suggestions on how
> to resolve this?  The part of our libc that defines _Zero is third party
> (Dinkum) and we're not super keen on monkeying with it.  What is the
> rationale for using a symbol starting with _Z as an autodetection for
> v3-abi?  Are there some symbols defined by gcc-3.x that start with _Z?  I'm
> just wondering if there might be some better way of dealing with this -
> perhaps have a special note in gnu-v3 binaries.  This could be handy for
> linkers as well for resolving library versionitus.

See my other message for a suggestion... All mangled names from the v3
compiler start with _Z.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

> OK, that's the problem.  What we should probably be doing in minsyms.c
> is checking for a valid v3 mangled name...

Ah.  That would probably be a fair bit of overhead to symbol loading though
if you're going to match every symbol name against some criteria.  I suppose
we could optimize by never doing the check again once the abi is set to v3.
Is there an existing function to check it or should I roll my own?  Also, I
didn't find any reference to gcc's mangling style in the manuals.  Is it
documented or is it 'read the code'?

cheers,

Kris

Re: gnu-v3-abi.c: problems w/ virtual base class

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 02:18:58PM -0500, Kris Warkentin wrote:
> > OK, that's the problem.  What we should probably be doing in minsyms.c
> > is checking for a valid v3 mangled name...
> 
> Ah.  That would probably be a fair bit of overhead to symbol loading though
> if you're going to match every symbol name against some criteria.  I suppose
> we could optimize by never doing the check again once the abi is set to v3.
> Is there an existing function to check it or should I roll my own?  Also, I
> didn't find any reference to gcc's mangling style in the manuals.  Is it
> documented or is it 'read the code'?

The way this works is:
  - We only care if the symbol starts with _Z.  Do it in the same
place we check for _Z now, instead of the switch_to_cp_abi call.

  - You just want to call cplus_demangle; be sure to free the result
if it returns non-NULL.

(and yes, stop checking once the ABI is set to v3).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gnu-v3-abi.c: problems w/ virtual base class

[Kris Warkentin]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

> The way this works is:
>   - We only care if the symbol starts with _Z.  Do it in the same
> place we check for _Z now, instead of the switch_to_cp_abi call.
>
>   - You just want to call cplus_demangle; be sure to free the result
> if it returns non-NULL.
>

Diff attached.  Seems to work quite nicely.  Thank you very much.  As
always, you are most helpful.

cheers,

Kris

[-- Attachment #2: minsym.diff --]
[-- Type: application/octet-stream, Size: 2339 bytes --]

Index: minsyms.c
===================================================================
RCS file: /product/tools/gdb/gdb/minsyms.c,v
retrieving revision 1.2
diff -c -r1.2 minsyms.c
*** minsyms.c	6 Sep 2002 20:20:43 -0000	1.2
--- minsyms.c	30 Oct 2002 19:52:08 -0000
***************
*** 952,958 ****
  
        /* Try to guess the appropriate C++ ABI by looking at the names 
  	 of the minimal symbols in the table.  */
!       {
  	int i;
  
  	for (i = 0; i < mcount; i++)
--- 952,958 ----
  
        /* Try to guess the appropriate C++ ABI by looking at the names 
  	 of the minimal symbols in the table.  */
!       if (!current_cp_abi_equals("gnu-v3")) {
  	int i;
  
  	for (i = 0; i < mcount; i++)
***************
*** 960,967 ****
  	    const char *name = SYMBOL_NAME (&objfile->msymbols[i]);
  	    if (name[0] == '_' && name[1] == 'Z')
  	      {
! 		switch_to_cp_abi ("gnu-v3");
! 		break;
  	      }
  	  }
        }
--- 960,971 ----
  	    const char *name = SYMBOL_NAME (&objfile->msymbols[i]);
  	    if (name[0] == '_' && name[1] == 'Z')
  	      {
! 	      	char *demangled;
! 		if((demangled = cplus_demangle(name, GNU_V3_DEMANGLING)) != NULL){
! 			free(demangled);
! 			switch_to_cp_abi ("gnu-v3");
! 			break;
! 		}
  	      }
  	  }
        }
Index: cp-abi.c
===================================================================
RCS file: /product/tools/gdb/gdb/cp-abi.c,v
retrieving revision 1.2
diff -c -r1.2 cp-abi.c
*** cp-abi.c	6 Sep 2002 20:20:42 -0000	1.2
--- cp-abi.c	30 Oct 2002 19:52:08 -0000
***************
*** 107,109 ****
--- 107,115 ----
    return 1;
  }
  
+ int
+ current_cp_abi_equals (const char *short_name)
+ {
+ 	return strcmp(current_cp_abi.shortname, short_name) == 0;
+ }
+ 
Index: cp-abi.h
===================================================================
RCS file: /product/tools/gdb/gdb/cp-abi.h,v
retrieving revision 1.2
diff -c -r1.2 cp-abi.h
*** cp-abi.h	6 Sep 2002 20:20:42 -0000	1.2
--- cp-abi.h	30 Oct 2002 19:52:08 -0000
***************
*** 168,173 ****
--- 168,174 ----
  extern struct cp_abi_ops current_cp_abi;
  extern int register_cp_abi (struct cp_abi_ops abi);
  extern int switch_to_cp_abi (const char *short_name);
+ extern int current_cp_abi_equals (const char *short_name);
  
  #endif