[Bug translator/16676] Inconsistently-biased addresses for ET_EXEC

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16676

--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
Here's another example, probing function("_start") because that will resolve
from the symbol table either way.  You can see this with "main" too, but it
will be resolving from debuginfo when available, so it's a very different path.

With coreutils-debuginfo:

$ stap -e 'probe process.function("_start") {next}' -c /usr/bin/ls -p2 
# probes
process("/usr/bin/ls").function("_start") /* pc=.absolute+0x4e3c */ /* <-
process("/usr/bin/ls").function("_start") */

Without coreutils-debuginfo:

$ stap -e 'probe process.function("_start") {next}' -c /usr/bin/ls -p2 
# probes
process("/usr/bin/ls").function("_start") /* pc=.dynamic+0x4e3c */ /* <-
process("/usr/bin/ls").function("_start") */


This explains why we aren't bitten by the buildid more often.  For
inode-uprobes, we always ultimately use a file-offset "address", but
.absolute/.dynamic affects how we get task_finder callbacks.  For .absolute, we
use a process callback and fake a 0 "relocation", so having an absolute
build-id address from there works fine.  For .dynamic, we use an mmap callback
where we know the relocation, so having a relative build-id address also works.

But process.plt is always giving me .absolute, which fails if the build-id
address was relative.  Unless it happens to follow a function probe, then it
will becomes .dynamic too. :/  So maybe process.plt just needs to trigger
something in dwfl to make it always follow suit?


(Honestly, I'd rather get rid of the ".absolute" concept, and convert
everything to ".dynamic" with relative addresses, but that may be more
invasive.)

-- 
You are receiving this mail because:
You are the assignee for the bug.