[PATCH] D103131: support debug info for alias variable

Tue Jun 1 14:24:09 PDT 2021

probinson added a comment.

In D103131#2791881 <https://reviews.llvm.org/D103131#2791881>, @dblaikie wrote:

> In D103131#2789493 <https://reviews.llvm.org/D103131#2789493>, @probinson wrote:
>
>>> Mixed feelings - somewhat in favor of "do the thing that's probably already fairly tested/known to work" (GCC's thing). But open to the idea that that approach has problems, for sure.
>>
>> "Known to work" for whom?  gdb, sure, because gcc/gdb cooperate on many things.
>
> Yep. Given the diversity of ways of expressing things in DWARF, no consumer will handle everything that could be produced in the way a producer might intend - so we do sort of have a defacto standard of "what would GCC do/what does GDB understand".
>
> But also GCC/GDB has had more implementation experience with DWARF in general, and with any feature we haven't implemented yet in particular - that I wouldn't throw out their representational choice too quickly - there may be important tradeoffs that were considered, implemented, and discarded due to limitations.

Well, they aren't the only ones with a decent amount of implementation experience, hrmph, my first contribution to DWARF was in 2002 (my name isn't on the proposal, but I co-developed it).

>> I'll have to check with my debugger guys whether this would work for us; and I'll just reiterate that it's certainly not what the DWARF spec suggests should be done.
>
> I don't agree that it's "certainly not what the DWARF spec suggests should be done" - the spec's pretty generous and exactly how a C or ELF level alias should be rendered in DWARF seems pretty unclear to me. For instance an alias is a symbol in the ELF file, arguably different from a source level alias like a typedef or using declaration that DW_TAG_imported_declaration seems to be promoted for.

The spec is generous and doesn't mandate (much), but what I'm referring to is DWARF 5 section 3.2.3 p.73 lines 1-3, "may be used as a general means to rename or provide an alias for an entity, regardless of the context" which seems like a pretty clear suggestion to me.
And I certainly would have thought `__attribute__((alias("oldname")))` counted as a source representation?

>> The Sony debugger will not be able to figure out the address of "newname" given the DWARF as emitted by gcc (because it looks like an external declaration with no address).  We'd much rather have the DW_TAG_imported_declaration that the original patch had.
>
> Good to know - any interest in the debugger supporting declarations without addresses? I guess there's no need for GCC compatibility?

No and no.  In general we seem to think that if you want to debug a CU, you should produce debug info for that CU.

I experimented with `extern int externalname;` and Clang doesn't emit a DIE for that at all, even if it's used; so I think the philosophy is not unsound, and is not inconsistent with how Clang behaves.  If you want to see data from another CU, you generate debug info for that CU.

> @kamleshbhalui  - perhaps you could run the gdb and lldb test suites without either change, then with both the variable declaration and imported declaration versions to see how the results vary? (Well, I guess the lldb test suite probably won't show any changes - but maybe worth running anyway) - along with the manual test you've described in the patch description, to demonstrate that both solutions address that?

No objection to running experiments, but Sony will want the imported_declaration construct regardless.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103131/new/

https://reviews.llvm.org/D103131