[Bug translator/16676] New: Inconsistently-biased addresses for ET_EXEC
jistone at redhat dot com
sourceware-bugzilla@sourceware.org
Sat Mar 8 00:12:00 GMT 2014
https://sourceware.org/bugzilla/show_bug.cgi?id=16676
Bug ID: 16676
Summary: Inconsistently-biased addresses for ET_EXEC
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: jistone at redhat dot com
We seem to have inconsistent bias behavior for the build-id in ET_EXEC, and the
problem seems to be from missing debuginfo. Note that prelink is often another
culprit of bias issues, but I did "prelink -u" for these first.
For my first point of comparison, consider ET_DYN /usr/bin/stap, whether or not
I have systemtap-debuginfo installed:
$ stap -e 'probe process.plt {next}' -c /usr/bin/stap \
-p3 -vv --poison-cache |& grep build-id
Found build-id in /usr/bin/stap, length 20, start at 0x284
For relocatable binaries, it's reasonable that we'd get a plain file offset.
Now ET_EXEC /usr/local/bin/stap, with debuginfo baked in:
$ stap -e 'probe process.plt {next}' -c /usr/local/bin/stap \
-p3 -vv --poison-cache |& grep build-id
Found build-id in /usr/local/bin/stap, length 20, start at 0x400284
It's not relocatable, and now we have an absolute address, ok.
Now ET_EXEC /usr/bin/ls without coreutils-debuginfo:
$ stap -e 'probe process.plt {next}' -c /usr/bin/ls \
-p3 -vv --poison-cache |& grep build-id
Found build-id in /usr/bin/ls, length 20, start at 0x284
So that's inconsistent -- not relocatable, but it's a file offset.
Now ET_EXEC /usr/bin/ls *with* coreutils-debuginfo:
$ stap -e 'probe process.plt {next}' -c /usr/bin/ls \
-p3 -vv --poison-cache |& grep build-id
Found build-id in /usr/bin/ls, length 20, start at 0x400284
We got the absolute address back!
That "Found build-id" line is in translate.cxx dump_build_id(). In a debugger
I can see that dwfl_module_build_id() is giving 0x400284 either way, but when
debuginfo is missing, the dwfl_module_relocate_address() kills the absolute
bias.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Systemtap
mailing list