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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
