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

[Will Dietz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-DebugInfo-Fix-handling-high_pc-as-a-constant-add-tes.patch
Type: application/octet-stream
Size: 6633 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131017/350392df/attachment.obj>