This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: rfc patch for buildid < shlib base address
> Yes, but it seems like elfutils 0.140 on this machine does not do that.
>
> ./stap -p4 --vp 033 -e 'probe process("/lib/libc-2.9.so").function("atoi").call {}' -w | grep 0x
> parsed 'atoi' -> func 'atoi'
> focused on module '/lib/libc-2.9.so = [0x7e73000-0x7fe6650, bias 0x0] file /usr/lib/debug/lib/libc-2.9.so.debug ELF machine i?86 (code 3)
> [...]
> dump_unwindsyms /lib/libc-2.9.so index=0 base=0x7e73000
> Found build-id in /lib/libc-2.9.so, length 20, end at 0x7e63198
I am looking at glibc-2.9-3.i686. Mine is prelinked to a different spot
than the spot yours uses:
eu-unstrip -n -e /lib/libc-2.9.so
0x13e000+0x173650 08d986453ccaf35f5cb4e94b5fa5507c32232e2e@0x13e184 /lib/libc-2.9.so -
eu-readelf -lS /lib/libc-2.9.so
[...]
[ 1] .note.gnu.build-id NOTE 0013e174 000174 000024 0 A 0 0 4
[...]
LOAD 0x000000 0x0013e000 0x0013e000 0x16db78 0x16db78 R E 0x1000
[...]
eu-unstrip -n -p $!
0x119000+0x23000 62a3ad35b38bb89ea69c019877e962042525ad9e@0x119124 /lib/ld-2.9.so - /lib/ld-2.9.so
0x13e000+0x171000 08d986453ccaf35f5cb4e94b5fa5507c32232e2e@0x13e184 /lib/libc-2.9.so - /lib/libc-2.9.so
[...]
(That $! being the PID of some 32-bit process, e.g $$ will do if the shell
binary is actually i386.)
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.
Thanks,
Roland