This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: better debug info for C++ cdtors, aliases, thunks and other trampolines


On Wed, Feb 24, 2016 at 5:07 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> Hi, Richard,
>
> Thanks for the feedback.  I'm afraid I can't quite figure out what
> you're getting at.  Please see below.
>
> On Feb 22, 2016, Richard Biener <richard.guenther@gmail.com> wrote:
>
>> I think this breaks early-debug assumptions in creating new decl DIEs
>> rather than just annotating old ones.
>
> Can you elaborate on it, or point at where these assumptions you allude
> to are documented?  I'm afraid I can't even tell whether the problem you
> allude to has to do with users of the debug hooks interface or the
> dwarf2out implementation thereof.
>
> Sure enough, we haven't created DIEs for user-introduced or C++ cdtor
> aliases before, so there are no DIEs for us to annotate, and there are
> no other uses of the debug hooks interface related with them, that could
> possibly interfere with them.
>
> Conversely, alias decls for which we *have* created DIEs are ones that
> cgraph turned into aliases; we do NOT want to pretend they're the same
> function, and ideally we'd emit separate debug information for them, but
> we can't retroactively figure out blocks, line numbers, variable
> locations and whatnot for the unrelated function that happened to
> optimize to the same executable code.  The best we can do for such
> aliases ATM is to leave them alone; that's unchanged.
>
>> So assemble_aliases is the wrong spot to do this.
>
> Here, you seem to be talking about *users* of the debug hooks interface.
> But then, I'd argue that the fact that debug info for aliases in
> dwarf2out is implemented as DIEs is an internal implementation detail,
> so why should assumptions made by the user side of the interface matter?

early-debug means that when dwarf2out_early_finish runs we have created
all type and decl DIEs.  From thereon only things like location expressions
should be added to existing DIEs.

So I was chiming in to see whether the added DIEs may cause any
issue when going forward with dropping frontends after dwarf2out_early_finish.
The function_decl call in expand_thunk looks dangerous, the new hooks
are self-contained enough that those late DIEs should (hopefully) cause
no issues (they can be seen as annotating an exiting DIE).

Richard.

> --
> Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]