Re: Using dwfl to enumerate frames of current thread

[Mark Wielaard <mjw at redhat dot com>]

On Fri, Aug 21, 2015 at 04:41:20PM +0200, Ben Gamari wrote:
> Mark Wielaard <mjw@redhat.com> writes:
> 
> > On Fri, Aug 21, 2015 at 09:35:14AM +0200, Ben Gamari wrote:
> >
> >> 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.
> >
> > And this is the problem. Sorry. I should have realized earlier.
> > We use the .debug_aranges to get a quick index of the CUs and which
> > address ranges they cover. In the case that there is no .debug_aranges
> > we could do a full scan of all CUs. But that is somewhat inefficient,
> > since no .debug_aranges could also mean that there really are no
> > CUs with address scope DIEs (however that is probably unlikely). But
> > if there is a .debug_aranges then we do assume it is complete. I am
> > thinking whether we should still scan all CUs anyway if we are
> > looking for an address that is really inside a module. But I think
> > that would quickly become very inefficient.
> >
> Brilliant! I'll try implementing these.

That would be best I think.

Meanwhile, to show it should really work, the attached horrible hack
makes it work with the current setup (if all CUs do have the pc ranges
attached).

Maybe we can turn this horrible hack into something that is less horrible
to make eu-addr2line and friends work better with missing/partial
.debug_aranges. But then we should really properly cache the results/CUs
we scanned. And make sure that we don't unnecessary scan all CUs if
the .debug_aranges are complete (sadly we cannot really tell just from
the .debug_aranges section itself).

> I know this is probably a "patches accepted" sort of task, but it would
> be great if libdw documented precisely what it expects from user objects
> in order to behave as expected. Even better would be optional warnings
> when the library doesn't find a DWARF annotation that it expects. As
> someone relatively new to DWARF, it is rather difficult to get a
> high-level view of what the significant differences are.

Yeah. Unfortunately DWARF is not very strict. A lot is left as a "quality
of implementation" issue. In practice that means we assume that the
minimum quality is what GCC outputs. And it isn't till some other DWARF
producer comes around that we even realize that is what we assumed was
the "quality" we needed.

Cheers,

Mark

Attachment: horrible_getsrc_hack.patch
Description: Text document