This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: rfc patch for buildid < shlib base address
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