Re: Using dwfl to enumerate frames of current thread

[Ben Gamari <ben at smart-cactus dot org>]

Mark Wielaard <mjw@redhat.com> writes:

> On Thu, 2015-08-20 at 17:02 +0200, Ben Gamari wrote:
>> Fair enough. However, I was basing my original statement not on the
>> output of elfutils' readelf but instead on libdwfl data structures
>> dumped in gdb.
>> 
>> As you may have realized by now, the problem begins in
>> dwfl_module_getsrc, which returns DWFL_E_ADDR_OUTOFRANGE.
>> If you look at the Dwfl_Module that gets passed to dwfl_module_getsrc,
>> you'll find that mod->ncu == 1 (which is confirmed by traversing the
>> mod->cu list). This struct me as rather odd.
>
> mod->ncu is the number of CUs that have been interned because they have
> been used. But you are correct that the Dwfl isn't seeing/using many
> CUs. The reason for that is that dwfl only caches the CUs which (program
> scope) addresses associated with it. There seem to be only 64 CUs that
> have a DW_AT_low_pc associated with the DW_TAG_compile unit (the same
> number as listed in .debug_aranges). All those seem to be generated by
> GCC for C files. None of the compile_unit generated by ghc seem to have
> address ranges associates with their CUs. Because of that libdwfl
> assumed that there are no program scopes inside that CU (only types) and
> so doesn't use them.
>
So I have added {low_high}_pc attributes to the compilation units yet
elfutils' addr2line is still not giving me line information,

    $ addr2line -e inplace/lib/bin/ghc-stage2 0x427150
    /opt/exp/ghc/ghc//ghc/Main.hs:79
    $ /opt/exp/elfutils-root/bin/addr2line -e inplace/lib/bin/ghc-stage2 0x427150
    ??:0

    $ addr2line -e ghc/stage2/build/Main.o 0x1be9
    /opt/exp/ghc/ghc//ghc/Main.hs:626
    $ /opt/exp/elfutils-root/bin/addr2line -e ghc/stage2/build/Main.o 0x1be9
    ??:0

The objects in question can be found here,

  * http://home.smart-cactus.org/~ben/Main.o
  * http://home.smart-cactus.org/~ben/ghc-stage2

I've compared the output from readelf and the differences that I've
noticed really don't seem like they should be significant,

 * GHC uses addresses for high_pc, whereas GCC appears to use a
   data8, meaning relative to low_pc. That being said, it appears that
   elfutils should handle this.

 * I use strings instead of strps.

 * I don't provide `decl_file`, `decl_line`, `type` or `prototyped`
   attributes on subprograms

I have noticed that `/opt/exp/elfutils-root/bin/readelf -e
ghc/stage2/build/Main.o --debug-dump=aranges` returns nothing for
GHC-produced objects whereas it does not for objects produced by GCC.

Cheers,

- Ben

Attachment: signature.asc
Description: PGP signature