[PATCH] Classify non-POD struct types more or less correctly on AMD64

[PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Kettenis]

This (together with the previous patch) fixes the problems I saw with
gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
I hope to revisit that later, after someone tells me how to properly
determine non-POD-ness.

Mark

P.S. The amd64_non_pod_p function should probably be moved to the
     generic cod, but we can do that later.


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
 
	* x86-64-tdep.c (amd64_non_pod_p): New function.
	(amd64_classify_aggregate): Return class memory for non-POD
	C++ structure types.

Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.110
diff -u -p -r1.110 x86-64-tdep.c
--- x86-64-tdep.c 10 Jan 2004 17:48:15 -0000 1.110
+++ x86-64-tdep.c 10 Jan 2004 17:51:19 -0000
@@ -270,6 +270,19 @@ amd64_merge_classes (enum amd64_reg_clas
 
 static void amd64_classify (struct type *type, enum amd64_reg_class class[2]);
 
+/* Return non-zero if TYPE is a non-POD structure or union type.  */
+
+static int
+amd64_non_pod_p (struct type *type)
+{
+  /* ??? A class with a base class certainly isn't POD, but does this
+     catch all non-POD structure types?  */
+  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
+    return 1;
+
+  return 0;
+}
+
 /* Classify TYPE according to the rules for aggregate (structures and
    arrays) and union types, and store the result in CLASS.  */
 
@@ -281,7 +294,7 @@ amd64_classify_aggregate (struct type *t
   /* 1. If the size of an object is larger than two eightbytes, or in
         C++, is a non-POD structure or union type, or contains
         unaligned fields, it has class memory.  */
-  if (len > 16)
+  if (len > 16 || amd64_non_pod_p (type))
     {
       class[0] = class[1] = AMD64_MEMORY;
       return;

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote:
> This (together with the previous patch) fixes the problems I saw with
> gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
> I hope to revisit that later, after someone tells me how to properly
> determine non-POD-ness.
> 
> Mark
> 
> P.S. The amd64_non_pod_p function should probably be moved to the
>      generic cod, but we can do that later.

Does the x86-64 ABI really pass non-POD and POD types of the same size
differently?  If so, I hope the ABI defines non-POD rather than relying
on the C++ definition, since we do not generally have enough
information in the debug info to determine whether a type is POD.

> +  /* ??? A class with a base class certainly isn't POD, but does this
> +     catch all non-POD structure types?  */
> +  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
> +    return 1;

No, at least any type with explicitly declared methods is non-POD.  For
DWARF you can probably get this right by checking for a non-artificial
method but for stabs you're SOL.

I don't remember what other things determine POD-ness.  I think
private/public may also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Kettenis]

   Date: Sat, 10 Jan 2004 13:36:22 -0500
   From: Daniel Jacobowitz <drow@mvista.com>

   On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote:
   > This (together with the previous patch) fixes the problems I saw with
   > gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
   > I hope to revisit that later, after someone tells me how to properly
   > determine non-POD-ness.
   > 
   > Mark
   > 
   > P.S. The amd64_non_pod_p function should probably be moved to the
   >      generic cod, but we can do that later.

   Does the x86-64 ABI really pass non-POD and POD types of the same size
   differently?  If so, I hope the ABI defines non-POD rather than relying
   on the C++ definition, since we do not generally have enough
   information in the debug info to determine whether a type is POD.

Oh joy, the ABI doesn't define POD-ness.  There's just a footnote
which says:

  The term POD is from the ANSI/ISO C++ Standard, and stands for Plain
  Old Data. Although the exact definition is technical, a POD is
  essentially a structure or union that could have been written in C;
  there cannot be any member functions, or base classes, or similar
  C++ extensions.

And yes, GCC really does pass them differently for aggregates up to 16
bytes in size.

   > +  /* ??? A class with a base class certainly isn't POD, but does this
   > +     catch all non-POD structure types?  */
   > +  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
   > +    return 1;

   No, at least any type with explicitly declared methods is non-POD.  For
   DWARF you can probably get this right by checking for a non-artificial
   method but for stabs you're SOL.

Tried that, and a lot of testcases started FAILing.  Apparently GCC
thinks differently.  In userdef.cc, we have a "class A1" with
explicitly declared methods, but GCC returns instances of "class A1"
in registers nevertheless.

Looks like we can't do very much about it.  Fortunately most real-life
classes will be larger than 16 bytes.

Mark

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Sat, Jan 10, 2004 at 07:58:39PM +0100, Mark Kettenis wrote:
>    Date: Sat, 10 Jan 2004 13:36:22 -0500
>    From: Daniel Jacobowitz <drow@mvista.com>
> 
>    On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote:
>    > This (together with the previous patch) fixes the problems I saw with
>    > gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
>    > I hope to revisit that later, after someone tells me how to properly
>    > determine non-POD-ness.
>    > 
>    > Mark
>    > 
>    > P.S. The amd64_non_pod_p function should probably be moved to the
>    >      generic cod, but we can do that later.
> 
>    Does the x86-64 ABI really pass non-POD and POD types of the same size
>    differently?  If so, I hope the ABI defines non-POD rather than relying
>    on the C++ definition, since we do not generally have enough
>    information in the debug info to determine whether a type is POD.
> 
> Oh joy, the ABI doesn't define POD-ness.  There's just a footnote
> which says:
> 
>   The term POD is from the ANSI/ISO C++ Standard, and stands for Plain
>   Old Data. Although the exact definition is technical, a POD is
>   essentially a structure or union that could have been written in C;
>   there cannot be any member functions, or base classes, or similar
>   C++ extensions.
> 
> And yes, GCC really does pass them differently for aggregates up to 16
> bytes in size.
> 
>    > +  /* ??? A class with a base class certainly isn't POD, but does this
>    > +     catch all non-POD structure types?  */
>    > +  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
>    > +    return 1;
> 
>    No, at least any type with explicitly declared methods is non-POD.  For
>    DWARF you can probably get this right by checking for a non-artificial
>    method but for stabs you're SOL.
> 
> Tried that, and a lot of testcases started FAILing.  Apparently GCC
> thinks differently.  In userdef.cc, we have a "class A1" with
> explicitly declared methods, but GCC returns instances of "class A1"
> in registers nevertheless.
> 
> Looks like we can't do very much about it.  Fortunately most real-life
> classes will be larger than 16 bytes.

Let's see.  gcc/config/i386/i386.c:ix86_return_in_memory:
  if (TARGET_64BIT)
    return !examine_argument (mode, type, 1, &needed_intregs, &needed_sseregs);

So an argument will be passed in memory if examine_argument returns 0.

examine_argument:
  int n = classify_argument (mode, type, class, 0);

  if (!n)
    return 0;
  for (n--; n >= 0; n--)
    switch (class[n])

      case X86_64_X87_CLASS:
      case X86_64_X87UP_CLASS:
        if (!in_return)
          return 0;
        break;

If any of the classes are X87_CLASS or X87UP_CLASS and !in_return,
the argument will be returned in memory.  But in_return is the third
argument, always 1 in this case.  So only if classify_argument returns
0 would a structure be returned in memory.

Looking at that function it looks like it will even return some classes
with baseclasses in registers.  I won't excerpt it here, as it's quite
large.  But it iterates over the baseclasses.  If none of them are
larger than 16 bytes (a given, if the derived class isn't larger than
16 bytes) or of a variable size (C++ classes are never variably sized I
don't think) or of TFmode/TCmode (128-bit long doubles), I believe that
the aggregate will be returned in registers.

IOW it doesn't look to me as if GCC implements the non-POD rule.  You
might wish to try returning a simple non-POD derived class and see what
GCC generates.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Kettenis]

[ This might interest GCC folks.  The problem we're facing here is
  that on AMD64, and other targets that return small structures in
  registers, it isn't clear how small C++ classes are returned.  Some
  are returned in registers and some are returned in memory.  The
  AMD64 ABI explicitly says that non-POD structures and unions are
  returned in memory, but GCC doesn't seem to be ABI-compliant here.
  Is this considered to be a bug?  ]

   Date: Sat, 10 Jan 2004 23:10:09 -0500
   From: Daniel Jacobowitz <drow@mvista.com>

   Looking at that function it looks like it will even return some classes
   with baseclasses in registers.  I won't excerpt it here, as it's quite
   large.  But it iterates over the baseclasses.  If none of them are
   larger than 16 bytes (a given, if the derived class isn't larger than
   16 bytes) or of a variable size (C++ classes are never variably sized I
   don't think) or of TFmode/TCmode (128-bit long doubles), I believe that
   the aggregate will be returned in registers.

That function just implements the rules for normal C structures.  Th
rules are a bit more complex than you say above, but that bit is
implemented correctly in GDB.  At least that's the intention.  The
decision to not pass certain C++ classes in registers is made
somewhere else, most notably in cp/class.c:finish_struct_bits(), where
TYPE_MODE is set to BLKmode, and TREE_ADDRESSABLE is set.  Both
conditions are enough to get the type returned in memory instead of
registers.  However, there are more places where TREE_ADDRESSABLE is
tweaked.

The 1996 ANSI C++ draft has the following statement about non-POD-ness:

  "A POD-struct is an aggregate class that has no non-static data members
  of type pointer to member, non-POD-struct, non-POD- union (or array of
  such types) or reference, and has no user-defined copy assignment
  operator and no user-defined destructor. Similarly, a POD-union is an
  aggregate union that has no non-static data members of type pointer to
  member, non-POD-struct, non-POD-union (or array of such types) or
  reference, and has no user-defined copy assignment operator and no
  user-defined destructor. A POD class is a class that is either a
  POD-struct or a POD-union."

So it doesn't say anything about baseclasses.  So the code I checked
in is defenitely wrong :-(.

   IOW it doesn't look to me as if GCC implements the non-POD rule.  You
   might wish to try returning a simple non-POD derived class and see what
   GCC generates.

Looks very much like it.  I can make a class with a user-defined copy
assignment operator that gets returned in registers by GCC.  So GCC
doesn't correctly implement the ABI :-(.

The same problem exist on other targets though.  I've seen problems on
64-bit SPARC and FreeBSD/i386 too.  The FreeBSD/i386 case is
interesting since the other i386 platforms are OK.  This is because
FreeBSD uses a different ABI, where -freg-struct-return is the
default.  The System V psABI says that all aggregate types are
returned in memory (-fpcc-struct-return).  This is probably the reason
why GCC has so many bugs related to returning small structs; the
majority of people hacking on GNU/Linux IA-32 boxen doesn't see the
problems.

Mark

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Jan Hubicka]

> [ This might interest GCC folks.  The problem we're facing here is
>   that on AMD64, and other targets that return small structures in
>   registers, it isn't clear how small C++ classes are returned.  Some
>   are returned in registers and some are returned in memory.  The
>   AMD64 ABI explicitly says that non-POD structures and unions are
>   returned in memory, but GCC doesn't seem to be ABI-compliant here.
>   Is this considered to be a bug?  ]
> 
>    Date: Sat, 10 Jan 2004 23:10:09 -0500
>    From: Daniel Jacobowitz <drow@mvista.com>
> 
>    Looking at that function it looks like it will even return some classes
>    with baseclasses in registers.  I won't excerpt it here, as it's quite
>    large.  But it iterates over the baseclasses.  If none of them are
>    larger than 16 bytes (a given, if the derived class isn't larger than
>    16 bytes) or of a variable size (C++ classes are never variably sized I
>    don't think) or of TFmode/TCmode (128-bit long doubles), I believe that
>    the aggregate will be returned in registers.
> 
> That function just implements the rules for normal C structures.  Th
> rules are a bit more complex than you say above, but that bit is
> implemented correctly in GDB.  At least that's the intention.  The
> decision to not pass certain C++ classes in registers is made
> somewhere else, most notably in cp/class.c:finish_struct_bits(), where
> TYPE_MODE is set to BLKmode, and TREE_ADDRESSABLE is set.  Both
> conditions are enough to get the type returned in memory instead of
> registers.  However, there are more places where TREE_ADDRESSABLE is
> tweaked.
> 
> The 1996 ANSI C++ draft has the following statement about non-POD-ness:

The non-POD clause in x86-64 ABI comes from Mark (GCC C++ maintainer)
and I must admit that I don't fully understand to these issues.
The decisions come from C++ frontend via TREE_ADDRESSABLE flag, as you
already noticed and they should comply what IA-64 ABI is saying (we
simply use that document for x86-64 ABI too).  Perhaps it is more
specific about what shall be passed in registers.
> 
>   "A POD-struct is an aggregate class that has no non-static data members
>   of type pointer to member, non-POD-struct, non-POD- union (or array of
>   such types) or reference, and has no user-defined copy assignment
>   operator and no user-defined destructor. Similarly, a POD-union is an
>   aggregate union that has no non-static data members of type pointer to
>   member, non-POD-struct, non-POD-union (or array of such types) or
>   reference, and has no user-defined copy assignment operator and no
>   user-defined destructor. A POD class is a class that is either a
>   POD-struct or a POD-union."
> 
> So it doesn't say anything about baseclasses.  So the code I checked
> in is defenitely wrong :-(.
> 
>    IOW it doesn't look to me as if GCC implements the non-POD rule.  You
>    might wish to try returning a simple non-POD derived class and see what
>    GCC generates.
> 
> Looks very much like it.  I can make a class with a user-defined copy
> assignment operator that gets returned in registers by GCC.  So GCC
> doesn't correctly implement the ABI :-(.

This seems obviously wrong to me.  If you do have testcase, you may want
to fill it in GCC bugzilla.  Especially if you can write simple testcase
that fails when copy constructor is not properly used.
I hope that Mark or Jason can take a look into this issue themselves.

Honza
> 
> The same problem exist on other targets though.  I've seen problems on
> 64-bit SPARC and FreeBSD/i386 too.  The FreeBSD/i386 case is
> interesting since the other i386 platforms are OK.  This is because
> FreeBSD uses a different ABI, where -freg-struct-return is the
> default.  The System V psABI says that all aggregate types are
> returned in memory (-fpcc-struct-return).  This is probably the reason
> why GCC has so many bugs related to returning small structs; the
> majority of people hacking on GNU/Linux IA-32 boxen doesn't see the
> problems.
> 
> Mark

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Gabriel Dos Reis]

Mark Kettenis <kettenis@chello.nl> writes:

| The 1996 ANSI C++ draft has the following statement about non-POD-ness:

using an old oudated document may lead to confusion (luckily, that is
not the case here).

|   "A POD-struct is an aggregate class that has no non-static data members
                        ^^^^^^^^^^^^^^^
|   of type pointer to member, non-POD-struct, non-POD- union (or array of
|   such types) or reference, and has no user-defined copy assignment
|   operator and no user-defined destructor. Similarly, a POD-union is an
|   aggregate union that has no non-static data members of type pointer to
|   member, non-POD-struct, non-POD-union (or array of such types) or
|   reference, and has no user-defined copy assignment operator and no
|   user-defined destructor. A POD class is a class that is either a
|   POD-struct or a POD-union."
| 
| So it doesn't say anything about baseclasses.

Sure it does.  A POD-struct ought to be an aggregate class, and an
aggregate class does not have base classes.

-- Gaby

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Mitchell]

> This seems obviously wrong to me.  If you do have testcase, you may want
> to fill it in GCC bugzilla.  Especially if you can write simple testcase
> that fails when copy constructor is not properly used.
> I hope that Mark or Jason can take a look into this issue themselves.

Jan's advise is exactly correct; you should file a bug report in
Bugzilla and then we can take a look.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Sun, Jan 11, 2004 at 01:37:31PM +0100, Mark Kettenis wrote:
> That function just implements the rules for normal C structures.  Th
> rules are a bit more complex than you say above, but that bit is
> implemented correctly in GDB.  At least that's the intention.  The
> decision to not pass certain C++ classes in registers is made
> somewhere else, most notably in cp/class.c:finish_struct_bits(), where
> TYPE_MODE is set to BLKmode, and TREE_ADDRESSABLE is set.  Both
> conditions are enough to get the type returned in memory instead of
> registers.  However, there are more places where TREE_ADDRESSABLE is
> tweaked.

Hi Mark,

As it happens I just ran into the same problem on ARM and on MIPS n32. 
I don't have a patch yet, but I can excerpt code I'm using at the
moment:

+      /* This is... rough.  If we have a non-trivial copy constructor or
+         destructor, use reference.  This should be in common code.  */
+      int i, j;
+      for (i = 0; i < TYPE_NFN_FIELDS (type); i++)
+       for (j = 0; j < TYPE_FN_FIELDLIST_LENGTH (type, i); j++)
+         {
+           struct fn_field *fn = TYPE_FN_FIELDLIST1 (type, i);
+           if (TYPE_FN_FIELD_ARTIFICIAL (fn, j))
+             continue;
+           if (TYPE_FN_FIELDLIST_NAME (type, i)[0] == '~')
+             return RETURN_VALUE_STRUCT_CONVENTION;
+           if (strncmp (TYPE_NAME (type),
+                        TYPE_FN_FIELDLIST_NAME (type, i),
+                        strlen (TYPE_NAME (type))) == 0
+               && (TYPE_FN_FIELDLIST_NAME (type, i)[strlen (TYPE_NAME (type))] == '\0'
+                   || TYPE_FN_FIELDLIST_NAME (type, i)[strlen (TYPE_NAME (type))] == '<')
+               && TYPE_NFIELDS (TYPE_FN_FIELD_TYPE (fn, j)) == 2
+               && TYPE_CODE (TYPE_FIELD_TYPE (TYPE_FN_FIELD_TYPE (fn, j), 1)) == TYPE_CODE_REF
+               && TYPE_TARGET_TYPE (TYPE_FIELD_TYPE (TYPE_FN_FIELD_TYPE (fn, j), 1)) == type)
+             return RETURN_VALUE_STRUCT_CONVENTION;
+         }

This doesn't address everything that GCC does to change the
pass-by-invisible-reference/return-by-invisible-reference behavior, but
it's a pretty good start and fixes one test in the GDB testsuite.  Note
that we can't implement the TYPE_FN_FIELD_ARTIFICIAL test with stabs.
This also doesn't handle anything about calling constructors or
destructors, which GDB just isn't set up for yet...

I don't know if this sort of information should be in the dwarf2
information somehow.  It definitely is in the C++ GNU v3 ABI:
  http://www.codesourcery.com/cxx-abi/abi.html#calls

I'm guessing that this is what the x86-64 ABI was referring to, rather
than the actual term POD.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Mitchell]

Daniel Jacobowitz wrote:

> I don't know if this sort of information should be in the dwarf2
> information somehow.  It definitely is in the C++ GNU v3 ABI:
>   http://www.codesourcery.com/cxx-abi/abi.html#calls

I think it should definitely be encoded in DWARF2.  (I don't know where; 
I just think it's a mistake for the debugger to be trying to figure this 
out for itself.  The rules are pretty subtle, and may be different from 
architecture to architecture, or compiler release to compiler release, 
even, if we make an intentional change.)

For stabs, you're probably hosed -- but then again, aren't you just 
generally hosed with stabs? :-)

> I'm guessing that this is what the x86-64 ABI was referring to, rather
> than the actual term POD.

Yes.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 07:38:31PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> 
> >I don't know if this sort of information should be in the dwarf2
> >information somehow.  It definitely is in the C++ GNU v3 ABI:
> >  http://www.codesourcery.com/cxx-abi/abi.html#calls
> 
> I think it should definitely be encoded in DWARF2.  (I don't know where; 
> I just think it's a mistake for the debugger to be trying to figure this 
> out for itself.  The rules are pretty subtle, and may be different from 
> architecture to architecture, or compiler release to compiler release, 
> even, if we make an intentional change.)
> 
> For stabs, you're probably hosed -- but then again, aren't you just 
> generally hosed with stabs? :-)

Amen.

> >I'm guessing that this is what the x86-64 ABI was referring to, rather
> >than the actual term POD.
> 
> Yes.

OK, thanks.  I don't believe there is an appropriate existing tag for
this, so if we get sufficiently fed up with trying to guess, we'll have
to propose one :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Sun, Jan 11, 2004 at 01:37:31PM +0100, Mark Kettenis wrote:
> That function just implements the rules for normal C structures.  Th
> rules are a bit more complex than you say above, but that bit is
> implemented correctly in GDB.  At least that's the intention.  The
> decision to not pass certain C++ classes in registers is made
> somewhere else, most notably in cp/class.c:finish_struct_bits(), where
> TYPE_MODE is set to BLKmode, and TREE_ADDRESSABLE is set.  Both
> conditions are enough to get the type returned in memory instead of
> registers.  However, there are more places where TREE_ADDRESSABLE is
> tweaked.

Hi Mark,

As it happens I just ran into the same problem on ARM and on MIPS n32. 
I don't have a patch yet, but I can excerpt code I'm using at the
moment:

+      /* This is... rough.  If we have a non-trivial copy constructor or
+         destructor, use reference.  This should be in common code.  */
+      int i, j;
+      for (i = 0; i < TYPE_NFN_FIELDS (type); i++)
+       for (j = 0; j < TYPE_FN_FIELDLIST_LENGTH (type, i); j++)
+         {
+           struct fn_field *fn = TYPE_FN_FIELDLIST1 (type, i);
+           if (TYPE_FN_FIELD_ARTIFICIAL (fn, j))
+             continue;
+           if (TYPE_FN_FIELDLIST_NAME (type, i)[0] == '~')
+             return RETURN_VALUE_STRUCT_CONVENTION;
+           if (strncmp (TYPE_NAME (type),
+                        TYPE_FN_FIELDLIST_NAME (type, i),
+                        strlen (TYPE_NAME (type))) == 0
+               && (TYPE_FN_FIELDLIST_NAME (type, i)[strlen (TYPE_NAME (type))] == '\0'
+                   || TYPE_FN_FIELDLIST_NAME (type, i)[strlen (TYPE_NAME (type))] == '<')
+               && TYPE_NFIELDS (TYPE_FN_FIELD_TYPE (fn, j)) == 2
+               && TYPE_CODE (TYPE_FIELD_TYPE (TYPE_FN_FIELD_TYPE (fn, j), 1)) == TYPE_CODE_REF
+               && TYPE_TARGET_TYPE (TYPE_FIELD_TYPE (TYPE_FN_FIELD_TYPE (fn, j), 1)) == type)
+             return RETURN_VALUE_STRUCT_CONVENTION;
+         }

This doesn't address everything that GCC does to change the
pass-by-invisible-reference/return-by-invisible-reference behavior, but
it's a pretty good start and fixes one test in the GDB testsuite.  Note
that we can't implement the TYPE_FN_FIELD_ARTIFICIAL test with stabs.
This also doesn't handle anything about calling constructors or
destructors, which GDB just isn't set up for yet...

I don't know if this sort of information should be in the dwarf2
information somehow.  It definitely is in the C++ GNU v3 ABI:
  http://www.codesourcery.com/cxx-abi/abi.html#calls

I'm guessing that this is what the x86-64 ABI was referring to, rather
than the actual term POD.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Mark Mitchell]

Daniel Jacobowitz wrote:

> I don't know if this sort of information should be in the dwarf2
> information somehow.  It definitely is in the C++ GNU v3 ABI:
>   http://www.codesourcery.com/cxx-abi/abi.html#calls

I think it should definitely be encoded in DWARF2.  (I don't know where; 
I just think it's a mistake for the debugger to be trying to figure this 
out for itself.  The rules are pretty subtle, and may be different from 
architecture to architecture, or compiler release to compiler release, 
even, if we make an intentional change.)

For stabs, you're probably hosed -- but then again, aren't you just 
generally hosed with stabs? :-)

> I'm guessing that this is what the x86-64 ABI was referring to, rather
> than the actual term POD.

Yes.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 07:38:31PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> 
> >I don't know if this sort of information should be in the dwarf2
> >information somehow.  It definitely is in the C++ GNU v3 ABI:
> >  http://www.codesourcery.com/cxx-abi/abi.html#calls
> 
> I think it should definitely be encoded in DWARF2.  (I don't know where; 
> I just think it's a mistake for the debugger to be trying to figure this 
> out for itself.  The rules are pretty subtle, and may be different from 
> architecture to architecture, or compiler release to compiler release, 
> even, if we make an intentional change.)
> 
> For stabs, you're probably hosed -- but then again, aren't you just 
> generally hosed with stabs? :-)

Amen.

> >I'm guessing that this is what the x86-64 ABI was referring to, rather
> >than the actual term POD.
> 
> Yes.

OK, thanks.  I don't believe there is an appropriate existing tag for
this, so if we get sufficiently fed up with trying to guess, we'll have
to propose one :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer