We currently expose R_LARCH_DELETE in our specs but it could be hard to properly use: for producers of object code, why emit the code at all, if you plan to stick this reloc to it right away to have the code removed by another program later?
For reference, the similar R_RISCV_DELETE is exclusively an internal concept only for BFD's relaxation pass:
// bfd/elfnn-riscv.c
/* Internal relocations used exclusively by the relaxation pass. */
#define R_RISCV_DELETE (R_RISCV_max + 1)
And LLVM doesn't define it at all.
So I suggest removing this reloc in a future revision of the ELF psABI document, making it reserved in the meantime. No program would consciously write this reloc kind to object files so compatibility would be preserved.
SixWeining
commented
9 months ago
We currently expose
R_LARCH_DELETEin our specs but it could be hard to properly use: for producers of object code, why emit the code at all, if you plan to stick this reloc to it right away to have the code removed by another program later?For reference, the similar
R_RISCV_DELETEis exclusively an internal concept only for BFD's relaxation pass:And LLVM doesn't define it at all.
So I suggest removing this reloc in a future revision of the ELF psABI document, making it reserved in the meantime. No program would consciously write this reloc kind to object files so compatibility would be preserved.