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: Mark Wielaard <mjw at redhat dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jwakely at redhat dot com, Dodji Seketeli <dodji at redhat dot com>
- Date: Fri, 03 Oct 2014 21:00:58 +0200
- 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>
On Fri, 2014-10-03 at 11:41 -0700, Cary Coutant wrote:
> > O. Then I was indeed wrong and defaulted does not impact ABI at all.
> > At least that is one worry less for the abi checkers :)
>
> As Siva mentioned, it does in fact impact the ABI. A class with a
> non-trivial destructor is not a POD, and affects the calling
> convention, so the debugger needs to know the difference. C++ ABI
> reference here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#return-value
>
> I've submitted a DWARF proposal to document the use of the
> DW_AT_artificial attribute on a default copy constructor or
> destructor.
Thanks for that reference. I was just stepping through gdb's
gdbarch_return_in_first_hidden_param_p to understand why Siva's example
did indeed seem to go wrong under GDB. That code is a little hairy with
all the arch specific indirections, so I am happy I can stop now :)
I can adjust my patch so that it does mark the declaration with
DW_AT_artificial if it is DECL_COPY_CONSTRUCTOR_P or DECL_DESTRUCTOR_P.
But maybe that is probably better done as a separate patch.
Or does it make sense to mark all defaulted special function members as
artificial instead of having a separate attribute for it? The (small)
advantage of having a separate attribute is that the consumer knows
whether it was explicitly defaulted.
Thanks,
Mark