This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.
- From: Siva Chandra <sivachandra at google dot com>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Cary Coutant <ccoutant at google dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jonathan Wakely <jwakely at redhat dot com>, Dodji Seketeli <dodji at redhat dot com>
- Date: Tue, 7 Oct 2014 07:13:31 -0700
- Subject: Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.
- Authentication-results: sourceware.org; auth=none
- References: <1412341922-7891-1-git-send-email-mjw at redhat dot com> <1412341922-7891-2-git-send-email-mjw at redhat dot com> <542EB00A dot 8040605 at redhat dot com> <1412346943 dot 5933 dot 36 dot camel at bordewijk dot wildebeest dot org> <542EB895 dot 2020705 at redhat dot com> <1412357525 dot 5933 dot 38 dot camel at bordewijk dot wildebeest dot org> <CAHACq4qATvGbJ6AdAM5_piksfUOaTfsif9Wpq6vDwOfszQtFQw at mail dot gmail dot com> <542EFCE2 dot 703 at redhat dot com> <CAGyQ6gwLqZnMv1PmMq=qg_aoKMJ3Ttd44vmn6kFJc3c9wyOzDg at mail dot gmail dot com> <543038ED dot 3030201 at redhat dot com> <CAGyQ6gzic=A2pkE2RjJV+B=EvCL+DxscPWs4Yqx2NF+dPH9oDw at mail dot gmail dot com> <54333A0D dot 8020700 at redhat dot com> <1412679940 dot 5534 dot 2 dot camel at bordewijk dot wildebeest dot org>
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