<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 4:58 AM Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com">matthewtpickering@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
Sorry for taking a few days to reply. It's not easy for you to compile<br>
a Haskell file to see the problem as the debug information is still<br>
WIP. Below I prove the IR for a simple hello world program which you<br>
can feed into llc.<br>
<br>
<a href="https://gist.github.com/05296933e37e87533a51d493b46aa48d" rel="noreferrer" target="_blank">https://gist.github.com/05296933e37e87533a51d493b46aa48d</a><br>
<br>
The `<a href="http://out.ir" rel="noreferrer" target="_blank">out.ir</a>` file can be passed straight to `llc`.<br>
<br>
Can you see anything obviously wrong?<br></blockquote><div><br>Unless I'm missing something else, I believe none of the instructions have !dbg locations attached (see, for example, a simple empty main.cpp compiled to LLVM IR by Clang, and note the !dbg attached to the ret instruction):<br><br><div>$ clang++-tot -emit-llvm -S -g -c -o - main.cpp</div><div>; ModuleID = 'main.cpp'</div><div>source_filename = "main.cpp"</div><div>target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"</div><div>target triple = "x86_64-unknown-linux-gnu"</div><div><br></div><div>; Function Attrs: noinline norecurse nounwind optnone uwtable</div><div>define dso_local i32 @main() #0 !dbg !7 {</div><div>entry:</div><div> ret i32 0, <b>!dbg !11</b></div><div>}</div><div><br></div><div>attributes #0 = { noinline norecurse nounwind optnone uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }</div><div><br></div><div>!<a href="http://llvm.dbg.cu">llvm.dbg.cu</a> = !{!0}</div><div>!llvm.module.flags = !{!3, !4, !5}</div><div>!llvm.ident = !{!6}</div><div><br></div><div>!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 8.0.0 (trunk 348415) (llvm/trunk 348416)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)</div><div>!1 = !DIFile(filename: "main.cpp", directory: "/usr/local/google/home/blaikie/dev/scratch/ghc_symbolizer_failure")</div><div>!2 = !{}</div><div>!3 = !{i32 2, !"Dwarf Version", i32 4}</div><div>!4 = !{i32 2, !"Debug Info Version", i32 3}</div><div>!5 = !{i32 1, !"wchar_size", i32 4}</div><div>!6 = !{!"clang version 8.0.0 (trunk 348415) (llvm/trunk 348416)"}</div><div>!7 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)</div><div>!8 = !DISubroutineType(types: !9)</div><div>!9 = !{!10}</div><div>!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)</div><div>!11 = !DILocation(line: 2, column: 1, scope: !7)</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Matt<br>
<br>
<br>
<br>
On Mon, Dec 3, 2018 at 6:37 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
> Yeah, not sure what GHC might be doing to generate novel DWARF that llvm-symbolizer can't consume - if you could create a small example (preferably source I can compile, but also LLVM IR (since it'll save me having to setup GHC, hopefully) I could feed into clang/llvm and get an object file out that demonstrates the llvm-symbolizer failure) that'd be helpful.<br>
><br>
> It may also be useful to compare Clang's behavior on similar C or C++ source to see if there are any critical differences in the DWARF that might explain the difference in behavior.<br>
><br>
> - Dave<br>
><br>
> On Mon, Dec 3, 2018 at 4:46 AM Dean Michael Berris <<a href="mailto:dean.berris@gmail.com" target="_blank">dean.berris@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> > On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> ><br>
>> > Is anyone able to help me with this or suggest where I might be able<br>
>> > to get help?<br>
>><br>
>> You’ve asked the right place, apologies for the delay I’m supposed to be answering these questions.<br>
>><br>
>> ><br>
>> > Matt<br>
>> > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering<br>
>> > <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> I am trying to add XRay support to the IR produced by GHC. Getting the<br>
>> >> basics working is not too complicated after adding the right function<br>
>> >> attribute but any analysis shows the function names but not the<br>
>> >> locations of the functions.<br>
>> >><br>
>> >> In particular, I run a program which has been instrumented as follows:<br>
>> >><br>
>> >> XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm<br>
>> >><br>
>> >> which then writes out an xray-log file.<br>
>> >><br>
>> >> ==4193==XRay: Log file in 'xray-log.llvm.hgD9oi'<br>
>> >> ==4193==Cleaned up log for TID: 4193<br>
>> >><br>
>> >> I then attempt to use the xray-account utility to analyse the log but<br>
>> >> whilst the functions are named, the locations of the functions are<br>
>> >> displayed as <invalid>:0:0:.<br>
>> >><br>
>> >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi<br>
>> >><br>
>> >> Functions with latencies: 5<br>
>> >> funcid count [ min, med, 90p, 99p,<br>
>> >> max] sum function<br>
>> >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040,<br>
>> >> 0.000040] 0.000089 <invalid>:0:0: fqux<br>
>> >> ... 4 lines omitted<br>
>> >><br>
>> >> If I then inspect the executable with llvm-dwarfdump, I can see that<br>
>> >> the debug information for fqux clearly lists the location as well.<br>
>> >><br>
>> >> 0x00000918: DW_TAG_subprogram<br>
>> >> DW_AT_low_pc (0x00000000004207c8)<br>
>> >> DW_AT_high_pc (0x0000000000420817)<br>
>> >> DW_AT_frame_base (DW_OP_reg7 RSP)<br>
>> >> DW_AT_linkage_name ("fqux")<br>
>> >> DW_AT_name ("fqux")<br>
>> >> DW_AT_decl_file ("TODO/llvm.hs")<br>
>> >> DW_AT_decl_line (8)<br>
>> >> DW_AT_external (true)<br>
>> >><br>
>> >> I suspect this is a problem with the DWARF information as when I try<br>
>> >> to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved<br>
>> >> from the above paste, the source location is also not reported.<br>
>> >><br>
>><br>
>> Yes, this is the issue. Getting llvm-symboliser to understand the DWARF information generated will get you better debugging information for XRay.<br>
>><br>
>> >> So, can anyone give me some practical advice about how to troubleshoot<br>
>> >> this problem/validate the DWARF information that is produced?<br>
>> >><br>
>> >> It might also be helpful is someone could point me to some<br>
>> >> documentation which explains at a high-level how llvm-symboliser<br>
>> >> works. Reading the source code was too difficult for me as I am not<br>
>> >> very experienced with C++ programming.<br>
>> >><br>
>><br>
>> I suspect all the usual resources apply — resources on DWARF4, and potentially looking at the various encodings. I’m not a DWARF expert, but<br>
>> David Blaikie might be able to help more specifically on emitting useful DWARF information via LLVM.<br>
>><br>
>> >> Many thanks for your help,<br>
>> >><br>
>><br>
>> Apologies for the delay again.<br>
>><br>
>> Cheers<br>
>><br>
>> -- Dean<br>
>><br>
</blockquote></div></div>