DWARF unmangled subprog name (DW_AT_name)

Hi,

I am looking for a way to get unmangled subprogram names from a DWARFContext. The name I want is available in the attribute DW_AT_name [1], but as far as I can tell this is only returned as a fallback in DWARFDebugInfoEntryMinimal::getSubroutineName when the linkage name is not available [2].

If this is not currently possible, is there any interest in adding such access to the public DebugInfo API? Perhaps with an additional “UnmangledName” option in DILineInfoSpecifier.

Thanks,
Isaiah

[1]: for example:

0x0001bb00: DW_TAG_subprogram [2]
DW_AT_MIPS_linkage_name [DW_FORM_strp] ( .debug_str[0x00007934] = “julia_vcat4473”)
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000913] = “vcat”)

[2] https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARFDebugInfoEntry.cpp#L279-L286

If you just want the DW_AT_name you should be able to iterate over the
DIEs and pull out the DW_AT_name attribute from all of the subprogram
DIEs. Is there some other use that you're looking for? I'm not quite
sure what you're trying to accomplish.

-eric

That doesn’t seem possible with the public API or am I mistaking?

Yeah, public API of DebugInfo library is quite minimalistic. But I agree with Eric - what is the use case for getting unmangled name from DIE?

The use case is getting the short name for backtraces. There are other options, but I figured it was worth a shot trying to access from the DWARF structure because what we need is already stored there anyway.

Thanks,
Isaiah

Have you checked out llvm-symbolize? It's what the asan folk
(including Alexey) have created for backtrace symbolication.

-eric

Have you checked out llvm-symbolize? It's what the asan folk
(including Alexey) have created for backtrace symbolication.

Yeah, we potentially can add some kind of option: "llvm-symbolizer
-print-short-function-names", I don't yet see why this would be valuable.
What's wrong with printing full function names?

The use case for this is in Julia backtraces. We don’t have a consistent way to mangle the function names for linkage (we might at some point in the future, but this is out of scope for now). Instead, we save whatever we want displayed in AT_name, but there’s no way to access that with the public API (it works nicely in gdb/lldb though).

The use case for this is in Julia backtraces. We don't have a consistent
way to mangle the function names for linkage (we might at some point in the
future, but this is out of scope for now). Instead, we save whatever we
want displayed in AT_name, but there's no way to access that with the
public API (it works nicely in gdb/lldb though).

Alright, I see why it makes sense. We can pass this information through
DILineInfoSpecifier. In fact, probably it makes sense to change the layout
of this structure:
there would be 3 types of file/line info (None, Regular, AbsoluteFilePath).
(though, probably we may make latter the default) and 3 types of function
name info (None, Name, LinkageName).

Alright, I see why it makes sense. We can pass this information through
DILineInfoSpecifier. In fact, probably it makes sense to change the layout
of this structure:
there would be 3 types of file/line info (None, Regular,
AbsoluteFilePath). (though, probably we may make latter the default) and 3
types of function name info (None, Name, LinkageName).

Here is a proposed patch, but with more limited scope than mentioned above.
Patch just adds LInkageName as a default-on option to the existing
DILineInfoSpecifier structure, and makes corresponding changes in the
necessary functions.

di_unmangled.patch (6.45 KB)

Going to let Alexey review, he's in that code much more often than I am.

-eric

I don't like this approach. Having two distinct flags (FunctionName and
LinkageName) describing the output format of a single field is confusing.
The value of LinkageName is silently ignored if FunctionName is not
specified. enum would be more appropriate here.

We would also need to test this behavior somehow. One of the option is to
expose it via llvm-symbolizer tool - and make its "--functions" flag take a
string value instead of a bool. I understand that it's extra work to do.
I'm ok with making these changes myself, but won't be able to get to it
until next week.

The use case for this is in Julia backtraces. We don't have a consistent
way to mangle the function names for linkage (we might at some point in the
future, but this is out of scope for now). Instead, we save whatever we
want displayed in AT_name, but there's no way to access that with the
public API (it works nicely in gdb/lldb though).

Alright, I see why it makes sense. We can pass this information through
DILineInfoSpecifier. In fact, probably it makes sense to change the layout
of this structure:
there would be 3 types of file/line info (None, Regular,
AbsoluteFilePath). (though, probably we may make latter the default) and 3
types of function name info (None, Name, LinkageName).

FYI I've implemented it in r209050.

Alright, I see why it makes sense. We can pass this information through

DILineInfoSpecifier. In fact, probably it makes sense to change the layout
of this structure:
there would be 3 types of file/line info (None, Regular,
AbsoluteFilePath). (though, probably we may make latter the default) and 3
types of function name info (None, Name, LinkageName).

FYI I've implemented it in r209050.

This works great - thank you!