[PATCH] RISC-V: Add support for vendor-specific relocations

[Nelson Chu]

On Thu, Apr 10, 2025 at 1:12 PM Alexey Lapshin <alexey.lapshin@espressif.com>
wrote:

> > define the R_RISCV_internal_first to 256 directly, after the end of
> vendor relocations.
>
> It seems having relocations with r_type greater than 255 is bad idea,
> because it will be corrupted when passed to macro (masked by 0xff):
>
> #define ELF32_R_INFO(s,t)       (((unsigned) (s) << 8) + ((t) & 0xff))
>
> I don't know why these 'internal' relocations were moved from
> elf_riscv_reloc_type
> to another ID (and still have duplicate in elf_riscv_reloc_type),
> but it looks like it's a 'postponed' issue to be resolved when most
> relocation IDs are reserved.
>

We can regard these internal relocation as they are not claimed to be
supported in the psABI, which means they shouldn't be generated to the
output.  Currently, all of them are used to help to do the linker
relaxations, replacing the original relocation to them, and then don't need
to be generated for the dynamic objects after resolving them, so that's why
they are internal.  So the r_type of them doesn't really matter, their
original number defined in the psABI have been freed, and some of them have
already been reused for other relocations.  Therefore, I think we just need
to give them an r_type, even if their r_type changes in every binutils
version, that should be fine.  The only thing that might be affected is
using --emit-relocs ld option, there was a patch for this, but it is
pending for some issues which I cannot remember.

Thanks
Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250411/b3adaa6a/attachment-0001.htm>