[PATCH] sframe: Allow input R_*_NONE relocations

H.J. Lu hjl.tools@gmail.com
Mon Jul 14 21:35:14 GMT 2025


On Tue, Jul 15, 2025 at 4:40 AM Indu Bhagat <indu.bhagat@oracle.com> wrote:
>
> On 7/14/25 12:29 PM, H.J. Lu wrote:
> > "ld -r" generates R_*_NONE relocations in sframe section if input
> > relocations in sframe section are against discarded section.  Allow
> > input R_*_NONE relocations if there are more relocation entries than
> > SFrame entries, instead of assuming number of SFrame entries == number
> > of relocation entries.
> >
> > bfd/
> >
> > PR ld/33127
> > * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Allow input
> > R_*_NONE relocations if there are more relocation entries than
> > SFrame entries.
> >
> > ld/
> >
> > PR ld/33127
> > * testsuite/ld-x86-64/sframe-reloc-2a.s: New file.
> > * testsuite/ld-x86-64/sframe-reloc-2b.s: Likewise.
> > * testsuite/ld-x86-64/x86-64.exp: Run PR ld/33127 tests.
> >
> > OK for master?
> >
>
> Hi H.J.,
>
> (Apologies for the delay.)
>
> I was trying to reason for SFrame if the generated R_*_NONE entries will
> always be towards the end.  To which the answer is : yes.
>
> SFrame merging code does rely on one-to-one order between FDEs and the
> relas.  So this patch should be OK.

I am checking it in.

> Also, looks like the presence of :
> 000000000030  000000000000 R_X86_64_NONE                        0
> 000000000030  000000000000 R_X86_64_NONE                        0
>
> in relas in general should not trip any existing consumer (including ld
> after this patch).
>
> Thanks again
> Indu
>
>


-- 
H.J.


More information about the Binutils mailing list