This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]