[PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

[Mark Wielaard]

On Mon, 2014-10-06 at 20:55 -0400, Jason Merrill wrote:
> On 10/06/2014 08:50 PM, Siva Chandra wrote:
> > On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill <jason@redhat.com> wrote:
> >> On 10/03/2014 05:41 PM, Siva Chandra wrote:
> >>>
> >>> I understand that knowing whether a copy-ctor or a d-tor has been
> >>> explicitly defaulted is not sufficient to determine the parameter
> >>> passing ABI. However, why is it not necessary? I could be wrong, but
> >>> doesn't the example I have given show that it is necessary?
> >>
> >> An implicitly declared 'tor can also be trivial.
> >
> > But, the question is whether it is required to determine the parameter
> > passing ABI. If there is no special marker to indicate that the user
> > declared 'tor is explicitly defaulted, then GDB could (in the absence
> > of other properties which make the 'tor non-trivial) incorrectly
> > conclude that the the 'tor is user defined, and hence not-trivial.
> 
> I've been thinking that we should just mark the 'tor as trivial or not 
> directly rather than hint at it.  Does GDB have enough information to 
> determine triviality if we just add defaulted info?

To be honest my original patches for a deleted/defaulted markers on
special member functions was really just meant to give the consumer a
way to know why GCC produced a declaration in the first place. Which I
still think is useful information for the consumer to have, but
certainly not enough to solve the abi problem with inferior function
calls Siva was seeing. Maybe GDB has enough information/smarts, but I
don't think other consumers have. So an explicit "trivial/non-trivial"
marker on special member functions seems like a good idea.

But looking at the definition of trivial copy constructor and trivial
destructor they do look more like class concepts instead of individual
constructor/destructor concepts (since they rely on properties of other
members and the base class). Currently GCC doesn't output declarations
unless the user declares them. So an implicit copy constructor or
destructor doesn't get a DWARF class member declaration. But I don't
think a consumer can conclude just from that fact that the copy
constructor or destructor is trivial. Nor can it asssume they are
non-trivial just because they are are respresented in DWARF. So should
we always output them and add a flag value to indicate
(non-trivialness). Or should we add attributes on the class itself?

Taking a step back and looking at the actual function that is causing
the trouble because abi/calling convention seems unclear. Which makes me
wonder if the issue isn't actually with the DWARF declaration of the
function that has special calling conventions. I am slightly surprised
the special return value passed in rule isn't expressed in the mangling
of the function name (or is it?). So the calling convention needs to be
interpreted from the DWARF representation. We already add a synthetic
formal parameter for "this" if necessary to be passed in. Why don't we
just add a similar synthetic "return" formal parameter if that is how
the function is really being invoked? That seems like a more direct way
to solve the inferior function call issue.

Cheers,

Mark