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

[Will Dietz]

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 :).

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