This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using dwfl to enumerate frames of current thread

Mark Wielaard <> 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/elfutils-root/bin/addr2line -e inplace/lib/bin/ghc-stage2 0x427150

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

The objects in question can be found here,


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.


- Ben

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]