This is an archive of the discontinued LLVM Phabricator instance.

[clang][DebugInfo] clang should not generate DW_TAG_subprogram entry without DW_AT_name
AbandonedPublic

Authored by alok on Mar 7 2022, 2:32 AM.

Details

Summary

Currently Clang is generating subprograms without DW_AT_name. which is fine for LLDB but other debuggers (GNU gdb) can not be forced to accept such DWARF due to DWARF standard mandating DW_AT_name attribute for subprograms.

As per DWARF standard Subroutine must have DW_AT_name attribute.
Please consider below lines from DWARF(5) document

3.3.1 General Subroutine and Entry Point Information
 The subroutine or entry point entry has a DW_AT_name attribute whose value is
 a null-terminated string containing the subroutine or entry point name. It may
 also have a DW_AT_linkage_name attribute as described in Section 2.22 on
 page 56.

Current behavior of Clang prevents gdb to show variables in shared/private clause of Openmp task construct.

Diff Detail

Event Timeline

alok created this revision.Mar 7 2022, 2:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 2:32 AM
alok requested review of this revision.Mar 7 2022, 2:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 2:32 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Hmmm... if this should be done within compiler side, I am wondering whether this should be resolved in AsmPrinter/DwarfDebug instead.
@aprantl please let me know wyt?

However, it looks like that after this hack the name here isn't the appropriate one... and it looks like something that debuggers should know how to workout ...

Yeah, happy to hear other perspectives - but my rough reaction is similar: putting mangled names in the "name" field seems problematic (consumer wouldn't necessarily know that the name should be demangled, for instance? Maybe?). So at the IR level maybe it's better to leave those in the linkage name - and maybe we workaround it in the backend when tuning for gdb - putting it in the DW_AT_name field because it's not ideal but the best we can do for GDB? (anyone filed a bug with GDB and/or DWARF for this? (I'd start with GDB and see if they're open to the idea directly - don't use the DWARF committee as an indirect way to request feature work for GDB unless they'd prefer it to be formalized before implementing it))

The various _ and __ names are probably OK as names, but the tests that end up producing mangled names into linkage names seem like not the right direction - maybe those entities need/are missing real names anyway? Might be worth comparing/contrasting with GCC's behavior for similar entities (at a glance at the tests, looks like some thunks are in this situation?)

Ideally, this would be fixed in GDB. If that's really not feasibly I would rather like to see this as a gdb debugger tuning instead f the default behavior.

alok abandoned this revision.May 22 2022, 9:54 PM

GNU gdb is now modified to accept functions with linkage name.

commit 6f9b09edaee43ea34d34b1998fe7b844834f251a
Author: Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
Date:   Sun May 22 21:46:06 2022 +0530

GNU gdb is now modified to accept functions with linkage name.

commit 6f9b09edaee43ea34d34b1998fe7b844834f251a
Author: Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
Date:   Sun May 22 21:46:06 2022 +0530

Nice work!