On Fri, Aug 21, 2015 at 09:35:14AM +0200, Ben Gamari wrote:
> 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.

Yes, it should. Using an offset for low_pc is just an optimization.
It might be worth emitting it as offset since that is smaller and
it removes a relocation that the linker will have to resolve.

>  * I use strings instead of strps.

That should also be fine, but using strps is often much more efficient
if you have identical strings (or strings that are the end of another
string).

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

Those are helpful, but shouldn't matter for just finding the lines.

> 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.

Cheers,

Mark