<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 8:46 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">David,<br>
<br>
Thanks a lot, this fixed the problem with symbol locations. Three more<br>
problems now arise which you might be able to help with.<br>
<br>
1. Compiling with `-O1` causes an error in the debug information<br>
verifier: "inlinable function call in a function with debug info must<br>
have a !dbg location"<br></blockquote><div><br></div><div>Yep, any inlinable within a function with debug info must have a debug location.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Compiling with `-O2` gives a different verifier error: "!dbg<br>
attachment points at wrong subprogram for function"<br></blockquote><div><br>Any !dbg location on an instruction in a function where the function has a subprogram attached through the !dbg must have a scope chain that leads to/ends with the same subprogram.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Are 1. and 2. bugs in the verifier? It seems that optimisation passes<br>
shouldn't affect the validity of debug information.<br></blockquote><div><br></div><div>Nah, just things the verifier can't see straight-off (in part it doesn't assume every function call could be inlined, nor does it walk the whole call graph to discover reachability).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3. Compiling with `-O0`, the verifier succeeds and then using<br>
llvm-stack, the complete call hierarchy is completely flat<br>
(an example run for loading into chrome://tracing -<br>
<a href="https://gist.githubusercontent.com/mpickering/a6dbaaeaa281b812cf3064a45e73a043/raw/9e5cdfffca1eb1ad269892af6bf7681ff195499e/chrome-tracing.json" rel="noreferrer" target="_blank">https://gist.githubusercontent.com/mpickering/a6dbaaeaa281b812cf3064a45e73a043/raw/9e5cdfffca1eb1ad269892af6bf7681ff195499e/chrome-tracing.json</a>)<br></blockquote><div><br>I'm not familiar with llvm-stack & chrome tracing to know what this means, sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
output of llvm-xray stack:<br>
<a href="https://gist.github.com/715859a15c088108a8114fcbf68926a5" rel="noreferrer" target="_blank">https://gist.github.com/715859a15c088108a8114fcbf68926a5</a><br>
<br>
log.yaml if that helps. <a href="https://gist.github.com/86fa7d8252967f6951b63d7a220f2846" rel="noreferrer" target="_blank">https://gist.github.com/86fa7d8252967f6951b63d7a220f2846</a><br>
<br>
Notice that level is 0 for all the entries. Any ideas what could cause this?<br></blockquote><div><br>I'd look at the verifier issues first, sounds like some of your debug info isn't quite complete in some ways?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Matt<br>
<br>
<br>
On Sun, Dec 9, 2018 at 9:13 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Dec 6, 2018 at 4:58 AM Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><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>
> $ clang++-tot -emit-llvm -S -g -c -o - main.cpp<br>
> ; ModuleID = 'main.cpp'<br>
> source_filename = "main.cpp"<br>
> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"<br>
> target triple = "x86_64-unknown-linux-gnu"<br>
><br>
> ; Function Attrs: noinline norecurse nounwind optnone uwtable<br>
> define dso_local i32 @main() #0 !dbg !7 {<br>
> entry:<br>
> ret i32 0, !dbg !11<br>
> }<br>
><br>
> 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" }<br>
><br>
> !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!0}<br>
> !llvm.module.flags = !{!3, !4, !5}<br>
> !llvm.ident = !{!6}<br>
><br>
> !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)<br>
> !1 = !DIFile(filename: "main.cpp", directory: "/usr/local/google/home/blaikie/dev/scratch/ghc_symbolizer_failure")<br>
> !2 = !{}<br>
> !3 = !{i32 2, !"Dwarf Version", i32 4}<br>
> !4 = !{i32 2, !"Debug Info Version", i32 3}<br>
> !5 = !{i32 1, !"wchar_size", i32 4}<br>
> !6 = !{!"clang version 8.0.0 (trunk 348415) (llvm/trunk 348416)"}<br>
> !7 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)<br>
> !8 = !DISubroutineType(types: !9)<br>
> !9 = !{!10}<br>
> !10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)<br>
> !11 = !DILocation(line: 2, column: 1, scope: !7)<br>
><br>
>><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>