From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============7463036001629519463=="
MIME-Version: 1.0
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Using dwfl to enumerate frames of current thread
Date: Thu, 20 Aug 2015 17:32:23 +0200
Message-ID: <1440084743.3117.143.camel@bordewijk.wildebeest.org>
In-Reply-To: 87h9nudmvg.fsf@smart-cactus.org

--===============7463036001629519463==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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 =3D=3D 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.

I am pondering if we can use the fact that they do have a
DW_AT_stmt_list to keep/cache them anyway. But I would suggest that ghc
outputs the program scope address ranges that the CU covers (either a
DW_AT_low_pc plus DW_AT_high_pc for a continues address range or a
DW_AT_low_pc plus DW_AT_ranges or non-contiguous address ranges). There
are other places where things probably go wrong if they aren't there.
elfutils tries to be efficient and not read a whole DIE tree unless it
thinks it needs it. One way to do that is to only read the children of a
program scope DIE if it covers the address we are looking for.
See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
advantage of:
"If an entity has no associated machine code, none of these attributes
are specified."

Cheers,

Mark

P.S. Is the DW_AT_language code you use for Haskell standardized?

--===============7463036001629519463==--