Dean Michael Berris via llvm-dev
2018-Dec-03 12:46 UTC
[llvm-dev] Source locations missing when using xray-account
> On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is anyone able to help me with this or suggest where I might be able > to get help?You’ve asked the right place, apologies for the delay I’m supposed to be answering these questions.> > Matt > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering > <matthewtpickering at gmail.com> wrote: >> >> Hi all, >> >> I am trying to add XRay support to the IR produced by GHC. Getting the >> basics working is not too complicated after adding the right function >> attribute but any analysis shows the function names but not the >> locations of the functions. >> >> In particular, I run a program which has been instrumented as follows: >> >> XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm >> >> which then writes out an xray-log file. >> >> ==4193==XRay: Log file in 'xray-log.llvm.hgD9oi' >> ==4193==Cleaned up log for TID: 4193 >> >> I then attempt to use the xray-account utility to analyse the log but >> whilst the functions are named, the locations of the functions are >> displayed as <invalid>:0:0:. >> >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi >> >> Functions with latencies: 5 >> funcid count [ min, med, 90p, 99p, >> max] sum function >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, >> 0.000040] 0.000089 <invalid>:0:0: fqux >> ... 4 lines omitted >> >> If I then inspect the executable with llvm-dwarfdump, I can see that >> the debug information for fqux clearly lists the location as well. >> >> 0x00000918: DW_TAG_subprogram >> DW_AT_low_pc (0x00000000004207c8) >> DW_AT_high_pc (0x0000000000420817) >> DW_AT_frame_base (DW_OP_reg7 RSP) >> DW_AT_linkage_name ("fqux") >> DW_AT_name ("fqux") >> DW_AT_decl_file ("TODO/llvm.hs") >> DW_AT_decl_line (8) >> DW_AT_external (true) >> >> I suspect this is a problem with the DWARF information as when I try >> to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved >> from the above paste, the source location is also not reported. >>Yes, this is the issue. Getting llvm-symboliser to understand the DWARF information generated will get you better debugging information for XRay.>> So, can anyone give me some practical advice about how to troubleshoot >> this problem/validate the DWARF information that is produced? >> >> It might also be helpful is someone could point me to some >> documentation which explains at a high-level how llvm-symboliser >> works. Reading the source code was too difficult for me as I am not >> very experienced with C++ programming. >>I suspect all the usual resources apply — resources on DWARF4, and potentially looking at the various encodings. I’m not a DWARF expert, but David Blaikie might be able to help more specifically on emitting useful DWARF information via LLVM.>> Many thanks for your help, >>Apologies for the delay again. Cheers -- Dean
David Blaikie via llvm-dev
2018-Dec-03 18:36 UTC
[llvm-dev] Source locations missing when using xray-account
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. 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. - Dave On Mon, Dec 3, 2018 at 4:46 AM Dean Michael Berris <dean.berris at gmail.com> wrote:> > > > On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Is anyone able to help me with this or suggest where I might be able > > to get help? > > You’ve asked the right place, apologies for the delay I’m supposed to be > answering these questions. > > > > > Matt > > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering > > <matthewtpickering at gmail.com> wrote: > >> > >> Hi all, > >> > >> I am trying to add XRay support to the IR produced by GHC. Getting the > >> basics working is not too complicated after adding the right function > >> attribute but any analysis shows the function names but not the > >> locations of the functions. > >> > >> In particular, I run a program which has been instrumented as follows: > >> > >> XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" > ./llvm > >> > >> which then writes out an xray-log file. > >> > >> ==4193==XRay: Log file in 'xray-log.llvm.hgD9oi' > >> ==4193==Cleaned up log for TID: 4193 > >> > >> I then attempt to use the xray-account utility to analyse the log but > >> whilst the functions are named, the locations of the functions are > >> displayed as <invalid>:0:0:. > >> > >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm > xray-log.llvm.hgD9oi > >> > >> Functions with latencies: 5 > >> funcid count [ min, med, 90p, 99p, > >> max] sum function > >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, > >> 0.000040] 0.000089 <invalid>:0:0: fqux > >> ... 4 lines omitted > >> > >> If I then inspect the executable with llvm-dwarfdump, I can see that > >> the debug information for fqux clearly lists the location as well. > >> > >> 0x00000918: DW_TAG_subprogram > >> DW_AT_low_pc (0x00000000004207c8) > >> DW_AT_high_pc (0x0000000000420817) > >> DW_AT_frame_base (DW_OP_reg7 RSP) > >> DW_AT_linkage_name ("fqux") > >> DW_AT_name ("fqux") > >> DW_AT_decl_file ("TODO/llvm.hs") > >> DW_AT_decl_line (8) > >> DW_AT_external (true) > >> > >> I suspect this is a problem with the DWARF information as when I try > >> to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved > >> from the above paste, the source location is also not reported. > >> > > Yes, this is the issue. Getting llvm-symboliser to understand the DWARF > information generated will get you better debugging information for XRay. > > >> So, can anyone give me some practical advice about how to troubleshoot > >> this problem/validate the DWARF information that is produced? > >> > >> It might also be helpful is someone could point me to some > >> documentation which explains at a high-level how llvm-symboliser > >> works. Reading the source code was too difficult for me as I am not > >> very experienced with C++ programming. > >> > > I suspect all the usual resources apply — resources on DWARF4, and > potentially looking at the various encodings. I’m not a DWARF expert, but > David Blaikie might be able to help more specifically on emitting useful > DWARF information via LLVM. > > >> Many thanks for your help, > >> > > Apologies for the delay again. > > Cheers > > -- Dean > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181203/f9685c7c/attachment-0001.html>
Matthew Pickering via llvm-dev
2018-Dec-06 12:57 UTC
[llvm-dev] Source locations missing when using xray-account
Hi David, Sorry for taking a few days to reply. It's not easy for you to compile a Haskell file to see the problem as the debug information is still WIP. Below I prove the IR for a simple hello world program which you can feed into llc. https://gist.github.com/05296933e37e87533a51d493b46aa48d The `out.ir` file can be passed straight to `llc`. Can you see anything obviously wrong? Matt On Mon, Dec 3, 2018 at 6:37 PM David Blaikie <dblaikie at gmail.com> wrote:> > 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. > > 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. > > - Dave > > On Mon, Dec 3, 2018 at 4:46 AM Dean Michael Berris <dean.berris at gmail.com> wrote: >> >> >> >> > On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> > >> > Is anyone able to help me with this or suggest where I might be able >> > to get help? >> >> You’ve asked the right place, apologies for the delay I’m supposed to be answering these questions. >> >> > >> > Matt >> > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering >> > <matthewtpickering at gmail.com> wrote: >> >> >> >> Hi all, >> >> >> >> I am trying to add XRay support to the IR produced by GHC. Getting the >> >> basics working is not too complicated after adding the right function >> >> attribute but any analysis shows the function names but not the >> >> locations of the functions. >> >> >> >> In particular, I run a program which has been instrumented as follows: >> >> >> >> XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm >> >> >> >> which then writes out an xray-log file. >> >> >> >> ==4193==XRay: Log file in 'xray-log.llvm.hgD9oi' >> >> ==4193==Cleaned up log for TID: 4193 >> >> >> >> I then attempt to use the xray-account utility to analyse the log but >> >> whilst the functions are named, the locations of the functions are >> >> displayed as <invalid>:0:0:. >> >> >> >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi >> >> >> >> Functions with latencies: 5 >> >> funcid count [ min, med, 90p, 99p, >> >> max] sum function >> >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, >> >> 0.000040] 0.000089 <invalid>:0:0: fqux >> >> ... 4 lines omitted >> >> >> >> If I then inspect the executable with llvm-dwarfdump, I can see that >> >> the debug information for fqux clearly lists the location as well. >> >> >> >> 0x00000918: DW_TAG_subprogram >> >> DW_AT_low_pc (0x00000000004207c8) >> >> DW_AT_high_pc (0x0000000000420817) >> >> DW_AT_frame_base (DW_OP_reg7 RSP) >> >> DW_AT_linkage_name ("fqux") >> >> DW_AT_name ("fqux") >> >> DW_AT_decl_file ("TODO/llvm.hs") >> >> DW_AT_decl_line (8) >> >> DW_AT_external (true) >> >> >> >> I suspect this is a problem with the DWARF information as when I try >> >> to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved >> >> from the above paste, the source location is also not reported. >> >> >> >> Yes, this is the issue. Getting llvm-symboliser to understand the DWARF information generated will get you better debugging information for XRay. >> >> >> So, can anyone give me some practical advice about how to troubleshoot >> >> this problem/validate the DWARF information that is produced? >> >> >> >> It might also be helpful is someone could point me to some >> >> documentation which explains at a high-level how llvm-symboliser >> >> works. Reading the source code was too difficult for me as I am not >> >> very experienced with C++ programming. >> >> >> >> I suspect all the usual resources apply — resources on DWARF4, and potentially looking at the various encodings. I’m not a DWARF expert, but >> David Blaikie might be able to help more specifically on emitting useful DWARF information via LLVM. >> >> >> Many thanks for your help, >> >> >> >> Apologies for the delay again. >> >> Cheers >> >> -- Dean >>