[llvm-dev] Source locations missing when using xray-account

[David Blaikie via llvm-dev]

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>