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