Issue with R_*_NONE relocs not getting ignored
H.J. Lu
hjl.tools@gmail.com
Mon Jan 8 15:19:33 GMT 2024
On Thu, Oct 26, 2023 at 8:33 AM Kris Van Hees <kris.van.hees@oracle.com> wrote:
>
> Hi,
>
> We ran into a problem with how DTrace processes relocations to determine the
> location of probe points in an ELF object. USDT probe points are just calls
> to (undefined) functions of a specific name, and when we process the ELF object
> we look for relocations to such symbols. We patch the text for the function
> at the call site with NOPs, and generate meta-data for this probe in a
> separate ELF object. We then change the type of the reloc to be R_X86_64_NONE,
> so that it will be ignored when the ELF object is linked into its target (so
> the linker won't overwrite our carefully placed NOPs).
>
> The reason why we don't just remove the reloc is that sometimes builds end
> up re-processing the ELF object and we want it to be able to regenerate the
> meta-data for the probes in that case.
>
> This does not work on x86 with PIC/PIE because the relocation validation in
> 382aae063227 ("x86: Only allow S + A relocations against absolute symbol") is
> not allowing R_X86_64_NONE relocations even though they have no functional
> purpose, i.e. they are ignored.
>
> I realize that the use of the relocation type R_X86_64_NONE is perhaps a bit
> unusual but it does support the need here in a quite elegant manner.
>
> Wouldl it be possible to allow R_X86_64_NONE relocations to pass the validation
> check introduced in the aforementioned commit since they are harmless? Or is
> there an alternative manner that the same can be accomplished?
>
> Thanks,
> Kris
Can you add a binary object testcase to
https://sourceware.org/bugzilla/show_bug.cgi?id=31047
Thanks.
--
H.J.
More information about the Binutils
mailing list