gcc HEAD rearranges stabs members

gcc HEAD rearranges stabs members

[Michael Elizabeth Chastain]

gcc rearranged the structure members in stabs+ debug info.
Ouch!  Ouch!

Last week (gdb 6.0, gcc HEAD 2003-12-23, binutils 2.14, -gstabs+):

  ptype class Foo
  type = class Foo {
    public:
      int x;
      int y;
      static int st;

      Foo & operator=(Foo const&);
      Foo(Foo const&);
      Foo(int, int);
      int operator!();
      operator int();
      int times(int);
  }

This week (gdb 6.0, gcc HEAD 2003-12-28, binutils 2.14, -gstabs+):

  ptype class Foo
  type = class Foo {
    public:
      int x;
      int y;
      static int st;

      Foo(int, int);
      int operator!();
      operator int();
      int times(int);
      Foo & operator=(Foo const&);
      Foo(Foo const&);
  }

Same change with gdb HEAD of course.

So I have to write a bunch of new patterns in gdb.cp/*.exp to match the
new output.  And I have to stare at all the differences and see if any
actual bugs crept in along with the rearrangement.

(David, this is why I like the HEAD test suite to keep working with
gdb 6.0 -- because the gdb 6.0 test suite just lost a lot of value
with gcc HEAD).

Hey, maybe some fixes crept in.  A guy can hope.

Michael C

Re: gcc HEAD rearranges stabs members

[Daniel Jacobowitz]

On Tue, Dec 30, 2003 at 03:57:20PM -0500, Michael Chastain wrote:
> gcc rearranged the structure members in stabs+ debug info.
> Ouch!  Ouch!
> 
> Last week (gdb 6.0, gcc HEAD 2003-12-23, binutils 2.14, -gstabs+):
> 
>   ptype class Foo
>   type = class Foo {
>     public:
>       int x;
>       int y;
>       static int st;
> 
>       Foo & operator=(Foo const&);
>       Foo(Foo const&);
>       Foo(int, int);
>       int operator!();
>       operator int();
>       int times(int);
>   }
> 
> This week (gdb 6.0, gcc HEAD 2003-12-28, binutils 2.14, -gstabs+):
> 
>   ptype class Foo
>   type = class Foo {
>     public:
>       int x;
>       int y;
>       static int st;
> 
>       Foo(int, int);
>       int operator!();
>       operator int();
>       int times(int);
>       Foo & operator=(Foo const&);
>       Foo(Foo const&);
>   }

So the synthetic members have moved to the end?

Might want to ping GCC about why this happened.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc HEAD rearranges stabs members

[Daniel Berlin]

> >       Foo & operator=(Foo const&);
> >       Foo(Foo const&);
> >   }
>
> So the synthetic members have moved to the end?
>
> Might want to ping GCC about why this happened.
Probably related to cgraph changes.

Re: gcc HEAD rearranges stabs members

[Daniel Jacobowitz]

On Tue, Dec 30, 2003 at 08:19:32PM -0500, Michael Chastain wrote:
> drow> Might want to ping GCC about why this happened.
> 
> It happened because the default abi version increased from 1 to 2.
> 
>   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01995.html
>   C++ PATCH: Change default ABI version to 2
> 
> Specifically, in cp/class.c:add_implicitly_declared_members,
> there is a test on ABI version:
> 
>   if (abi >= 2)
>     /* G++ 3.2 put the implicit destructor at the *beginning* of the
>        list, which cause the destructor to be emitted in an incorrect
>        location in the vtable.  */
>     TYPE_METHODS (t) = chainon (TYPE_METHODS (t), implicit_fns);

Oh cute.  Debug info is emitted in vtable order, so that explains why
the output changed.

Thanks for looking it up!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc HEAD rearranges stabs members

[Michael Elizabeth Chastain]

drow> Might want to ping GCC about why this happened.

It happened because the default abi version increased from 1 to 2.

  http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01995.html
  C++ PATCH: Change default ABI version to 2

Specifically, in cp/class.c:add_implicitly_declared_members,
there is a test on ABI version:

  if (abi >= 2)
    /* G++ 3.2 put the implicit destructor at the *beginning* of the
       list, which cause the destructor to be emitted in an incorrect
       location in the vtable.  */
    TYPE_METHODS (t) = chainon (TYPE_METHODS (t), implicit_fns);
  else
    {
      if (warn_abi && virtual_dtor)
	warning ("...");
      *f = TYPE_METHODS (t);
      TYPE_METHODS (t) = implicit_fns;
    }

So the gcc folks know what they are doing.  But we have to beware that
gcc HEAD might have new bugs because a bunch of little things change
with the ABI version.  I will have to sift through a bunch of noise to
see if there are any real regressions.

Michael C