<div dir="ltr"><div class="gmail_extra">Hi Will,</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 17, 2013 at 12:51 AM, Will Dietz <span dir="ltr"><<a href="mailto:w@wdtz.org" target="_blank">w@wdtz.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Fixes bug exposed by tsan lit tests where addresses fail to be<br>

symbolized on my system (x86_64 linux).<br>
<br>
An example of this failure can be seen with this binary[1]:<br>
<br>
$ unxz ./thread_leak.3.c.tmp.xz<br>
<br>
Using llvm-symbolizer from ToT:<br>
<br>
$ echo ./thread_leak3.c.tmp 0x020560 | ~/llvm/build/bin/llvm-symbolizer<br>
__interceptor_pthread_create<br>
??:0:0<br>
<br>
And after:<br>
<br>
$ echo ./thread_leak3.c.tmp 0x020560|~/llvm/build/bin/llvm-symbolizer<br>
__interceptor_pthread_create<br>
/home/will/llvm/latest/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:876:0<br>
<br>
Proposed patch attached.</blockquote><div><br></div><div>Interesting. I agree that llvm-symbolizer should perform at least as good with --inlining=true</div><div>than without it, but the fix should probably go the DWARF parser in DebugInfo library.</div>
<div><br></div><div>Here's the DWARF entry for __interceptor_pthread_create in your binary:</div><div><br></div><div><div>0x0002c37a:   DW_TAG_subprogram [182] *</div><div>                DW_AT_external [DW_FORM_flag_present]   (true)</div>
<div>                DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00012957] = "__interceptor_pthread_create")</div><div>                DW_AT_decl_file [DW_FORM_data1] (0x01)</div><div>                DW_AT_decl_line [DW_FORM_data2] (0x036b)</div>
<div>                DW_AT_type [DW_FORM_ref4]       (cu + 0x49a0 => {0x00014e6e})</div><div>                DW_AT_low_pc [DW_FORM_addr]     (0x0000000000020560)</div><div>                DW_AT_high_pc [DW_FORM_data8]   (0x000000000000015f)   <-------------------- [1]</div>
<div>                DW_AT_frame_base [DW_FORM_exprloc]      (<0x1> 9c )</div><div>                DW_AT_Unknown_2117 [DW_FORM_flag_present]       (true)</div><div>                DW_AT_sibling [DW_FORM_ref4]    (cu + 0x1c267 => {0x0002c735})</div>
</div><div><br></div><div>[1] DW_AT_high_pc has different DW_FORM here and actually means the size of the functions, not its largest address.</div><div>My guess is DWARF parser doesn't know about this and fails to build a correct address range for the function. I'm going</div>
<div>to investigate this soon.</div><div><br></div><div>Thanks for the reproducer!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
~Will<br>
<br>
[1] <a href="http://wdtz.org/files/thread_leak3.c.tmp.xz" target="_blank">http://wdtz.org/files/thread_leak3.c.tmp.xz</a><br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>