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

[Siva Chandra]

On Tue, Oct 7, 2014 at 4:05 AM, Mark Wielaard <mjw@redhat.com> wrote:
> 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?

I also feel that triviality of special methods is more like a class
concept. Also, this concept is specified by the language.

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

Triviality (or not) is specified by the language. Similarly, the
'this' pointer is specified by the language. However, function calling
convention is specified by the ABI. ISTR that DWARF cannot/should not
describe the ABI. May be I am wrong, but if it is indeed possible to
specify the ABI in DWARF, then I agree that it probably is the best
solution for function call issue.

Thanks,
Siva Chandra