Thanks for all the answers to this! Here are some clarifications
and context.
> It appears to me that whatever you are trying to do is not possible
> portibly on Linux at this time. Could you fill us in?
As part of writing profiling and debugging tools, I am trying to rewrite the PLT
table to hook into some symbols of shared libraries. This technique is quite common
and is already used in a considerable number of debuggers, profilers and elf inspection
tools. Currently, the way this is handled is "not at all" or "checking against the base
address and heuristically assuming that is an offset if the address is less than the base",
which is suboptimal. This use case may sound "advanced" or "hacky" but this is quite a
common technique for doing profilers, debuggers, state inspection tools and other related
tooling.
Notice that the lack of anything predictable here makes these tools be more unreliable
across libc implementations (most people assume it "works" based on what glibc does
but even old glibcs seem to be inconsistent with this).
Apart from some advanced profiling/debugger use cases, I think there are several important
use cases here that would benefit from some way to handle this at runtime. For instance,
inspecting the string tables and symbol tables and other entries in the dynamic section.
Here are (some) examples of software dealing with this problem in the wild:
There are many, many more examples of tools that are not aware of this incompatibility and are doing it wrong. Just some examples
of this:
(and many more).
I think there is value on having some way to programmatically efficiently know how to interpret these addresses. At the very least,
allowing these tools to work correctly on muslc without even more hacks on top.
Thanks for your consideration!