[LLVMdev] DWARF unmangled subprog name (DW_AT_name)

[Alexey Samsonov]

On Wed, May 7, 2014 at 1:44 PM, Alexey Samsonov <samsonov at google.com> wrote:

>
> On Wed, May 7, 2014 at 11:38 AM, Keno Fischer <
> kfischer at college.harvard.edu> wrote:
>
>> 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.


>
>
>>
>>
>> On Wed, May 7, 2014 at 2:36 PM, Alexey Samsonov <samsonov at google.com>wrote:
>>
>>>
>>> On Wed, May 7, 2014 at 11:33 AM, Eric Christopher <echristo at gmail.com>wrote:
>>>
>>>> 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?
>>>
>>>
>>>>
>>>> -eric
>>>>
>>>> On Wed, May 7, 2014 at 11:28 AM, Isaiah Norton <isaiah.norton at gmail.com>
>>>> wrote:
>>>> > 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
>>>> >
>>>> >
>>>> > On Wed, May 7, 2014 at 12:24 PM, Alexey Samsonov <samsonov at google.com
>>>> >
>>>> > wrote:
>>>> >>
>>>> >> 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?
>>>> >>
>>>> >>
>>>> >> On Tue, May 6, 2014 at 11:21 PM, Keno Fischer
>>>> >> <kfischer at college.harvard.edu> wrote:
>>>> >>>
>>>> >>> That doesn't seem possible with the public API or am I mistaking?
>>>> >>>
>>>> >>>
>>>> >>> On Wed, May 7, 2014 at 12:13 AM, Eric Christopher <
>>>> echristo at gmail.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> On Tue, May 6, 2014 at 8:09 PM, Isaiah Norton <
>>>> isaiah.norton at gmail.com>
>>>> >>>> wrote:
>>>> >>>> > 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
>>>> >>>> _______________________________________________
>>>> >>>> LLVM Developers mailing list
>>>> >>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> LLVM Developers mailing list
>>>> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Alexey Samsonov, Mountain View, CA
>>>> >>
>>>> >> _______________________________________________
>>>> >> LLVM Developers mailing list
>>>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > LLVM Developers mailing list
>>>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Alexey Samsonov, Mountain View, CA
>>>
>>
>>
>
>
> --
> Alexey Samsonov, Mountain View, CA
>



-- 
Alexey Samsonov, Mountain View, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140516/689c20ec/attachment.html>