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).> > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140507/6ff2b607/attachment.html>
> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140509/0e0ed3be/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: di_unmangled.patch Type: text/x-patch Size: 6607 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140509/0e0ed3be/attachment.bin>
Eric Christopher
2014-May-09 17:30 UTC
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
Going to let Alexey review, he's in that code much more often than I am. -eric On Fri, May 9, 2014 at 4:50 AM, Isaiah Norton <isaiah.norton at gmail.com> wrote:> >> 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. >
On Fri, May 9, 2014 at 4:50 AM, Isaiah Norton <isaiah.norton at gmail.com>wrote:> > 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. > >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. -- Alexey Samsonov, Mountain View, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140509/d0702d5e/attachment.html>
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>
> > 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! 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/20140518/c023ad89/attachment.html>