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 <[email protected]> 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? -- 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
