[PATCH] LLVMSymbolizer: Use alternative method if no inlining frames found.

[Alexey Samsonov]

On Wed, Oct 30, 2013 at 1:32 PM, Will Dietz <w at wdtz.org> wrote:

> Done in r193711, thanks for the fix!
>

Great, thank you.


>
> ~Will
>
> On Mon, Oct 28, 2013 at 6:21 PM, Alexey Samsonov <samsonov at google.com>
> wrote:
> >
> > On Thu, Oct 17, 2013 at 11:56 AM, Will Dietz <w at wdtz.org> wrote:
> >>
> >> Ah, well after your DebugInfo change re:form classes lands,
> >> this patch is almost certainly going about this the wrong way.
> >>
> >> If you'd like I can update the patch, but since you just refactored
> >> things to support doing this properly it seems you should just
> >> go ahead and fix this yourself (compared to overhead of managing me
> doing
> >> it).
> >>
> >> The testcase is probably still useful regardless :).
> >
> >
> > Hi Will, I think I've fixed the problem in r193555.
> > Could you please commit your testcase with the following improvements:
> > * Add the original source code with descriptions of how to build the
> object
> > file (which compiler was used etc.) See
> > test/DebugInfo/Inputs/dwarfdump-test.cc for inspiration.
> > * Rewrite the test to use llvm-symbolizer (it will probably be shorter),
> or
> > just extend test/DebugInfo/llvm-symbolizer.test
> >
> > Thanks!
> >
> >>
> >>
> >> No worries, would rather see this done properly for sure.
> >> Thanks!
> >>
> >> ~Will
> >>
> >>
> >> On Thu, Oct 17, 2013 at 1:20 PM, Will Dietz <w at wdtz.org> wrote:
> >> > Great, thanks! You were absolutely right regarding the high_pc thing,
> >> > sorry for misdiagnosing the issue (and thanks for figuring this out!).
> >> >
> >> > Attached is a patch that attempts to address this issue,
> >> > with included test case (by far the larger time-sink after your
> >> > spot-on analysis).
> >> >
> >> > Thanks for taking a look and letting me take a crack at fixing this
> >> > properly :).
> >> >
> >> > ~Will
> >> >
> >> >
> >> > On Thu, Oct 17, 2013 at 5:49 AM, Alexey Samsonov <samsonov at google.com
> >
> >> > wrote:
> >> >> Hi Will,
> >> >>
> >> >> On Thu, Oct 17, 2013 at 12:51 AM, Will Dietz <w at wdtz.org> wrote:
> >> >>>
> >> >>> Fixes bug exposed by tsan lit tests where addresses fail to be
> >> >>> symbolized on my system (x86_64 linux).
> >> >>>
> >> >>> An example of this failure can be seen with this binary[1]:
> >> >>>
> >> >>> $ unxz ./thread_leak.3.c.tmp.xz
> >> >>>
> >> >>> Using llvm-symbolizer from ToT:
> >> >>>
> >> >>> $ echo ./thread_leak3.c.tmp 0x020560 |
> >> >>> ~/llvm/build/bin/llvm-symbolizer
> >> >>> __interceptor_pthread_create
> >> >>> ??:0:0
> >> >>>
> >> >>> And after:
> >> >>>
> >> >>> $ echo ./thread_leak3.c.tmp
> 0x020560|~/llvm/build/bin/llvm-symbolizer
> >> >>> __interceptor_pthread_create
> >> >>>
> >> >>>
> >> >>>
> /home/will/llvm/latest/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:876:0
> >> >>>
> >> >>> Proposed patch attached.
> >> >>
> >> >>
> >> >> Interesting. I agree that llvm-symbolizer should perform at least as
> >> >> good
> >> >> with --inlining=true
> >> >> than without it, but the fix should probably go the DWARF parser in
> >> >> DebugInfo library.
> >> >>
> >> >> Here's the DWARF entry for __interceptor_pthread_create in your
> binary:
> >> >>
> >> >> 0x0002c37a:   DW_TAG_subprogram [182] *
> >> >>                 DW_AT_external [DW_FORM_flag_present]   (true)
> >> >>                 DW_AT_name [DW_FORM_strp]       (
> >> >> .debug_str[0x00012957] =
> >> >> "__interceptor_pthread_create")
> >> >>                 DW_AT_decl_file [DW_FORM_data1] (0x01)
> >> >>                 DW_AT_decl_line [DW_FORM_data2] (0x036b)
> >> >>                 DW_AT_type [DW_FORM_ref4]       (cu + 0x49a0 =>
> >> >> {0x00014e6e})
> >> >>                 DW_AT_low_pc [DW_FORM_addr]     (0x0000000000020560)
> >> >>                 DW_AT_high_pc [DW_FORM_data8]   (0x000000000000015f)
> >> >> <-------------------- [1]
> >> >>                 DW_AT_frame_base [DW_FORM_exprloc]      (<0x1> 9c )
> >> >>                 DW_AT_Unknown_2117 [DW_FORM_flag_present]
> (true)
> >> >>                 DW_AT_sibling [DW_FORM_ref4]    (cu + 0x1c267 =>
> >> >> {0x0002c735})
> >> >>
> >> >> [1] DW_AT_high_pc has different DW_FORM here and actually means the
> >> >> size of
> >> >> the functions, not its largest address.
> >> >> My guess is DWARF parser doesn't know about this and fails to build a
> >> >> correct address range for the function. I'm going
> >> >> to investigate this soon.
> >> >>
> >> >> Thanks for the reproducer!
> >> >>
> >> >>>
> >> >>> ~Will
> >> >>>
> >> >>> [1] http://wdtz.org/files/thread_leak3.c.tmp.xz
> >> >>>
> >> >>> _______________________________________________
> >> >>> llvm-commits mailing list
> >> >>> llvm-commits at cs.uiuc.edu
> >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Alexey Samsonov, MSK
> >
> >
> >
> >
> > --
> > Alexey Samsonov, MSK
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131030/e8fa28fb/attachment.html>