Re: rfc patch for buildid < shlib base address

[Mark Wielaard <mjw at redhat dot com>]

Hi,

On Wed, 2009-02-25 at 13:52 +0100, Mark Wielaard wrote: 
> On Tue, 2009-02-24 at 18:38 -0800, Roland McGrath wrote:
> > > Yes, but it seems like elfutils 0.140 on this machine does not do that.
> > [...]
> > If those eu-* tools make all those numbers come out right given your binary
> > version and its prelinking state (as shown by eu-readelf), then something
> > funny is going on that only stap sees.
> 
> It seems that at least on my system the numbers come out right, and stap
> sees the same thing. As far as I can see translate.cxx (dump_unwindsyms)
> does the right thing (although it should really be using
> dwfl_module_relocate_address() instead of adjusting the absolute address
> directly, except that would not work with elfutils < 0.138).

I am now also seeing this. Double checking libc seems everything is OK,
prelinked at 0x126000.

$ eu-unstrip -n -e /lib/libc-2.9.so 
0x126000+0x173650 08d986453ccaf35f5cb4e94b5fa5507c32232e2e@0x126184 /lib/libc-2.9.so /usr/lib/debug/lib/libc-2.9.so.debug 

$ eu-readelf -lS /lib/libc-2.9.so 
[ 1] .note.gnu.build-id   NOTE         00126174 000174 000024  0 A      0   0  4
[...]
  LOAD           0x000000 0x00126000 0x00126000 0x16db78 0x16db78 R E 0x1000

$ eu-unstrip -n -p $$
0x126000+0x171000 08d986453ccaf35f5cb4e94b5fa5507c32232e2e@0x126184 /lib/libc-2.9.so /usr/lib/debug/lib/libc-2.9.so.debug /lib/libc-2.9.so

But in our dwfl_getmodules() callback for /lib/libc-2.9.so we get
base=0x136000. While dwfl_module_build_id() gives a addr=0x126184.
So, when we then either call dwfl_module_relocate_address() or manually
substract base we end up with a negative address.

So, the address returned by dwfl_module_build_id() looks correct if
taken at the original prelinked address. But mod->main.bias is not equal
to that address, so there is no easy way to turn this into an relative
address that we need.

This is with elfutils 0.140.

Cheers,

Mark