Add relaxation relocations

[cloudspurs]

No description provided.

[xen0n]

cc @MaskRay @xry111

Unfortunately I can't allocate time for this at present.

[xen0n]

binutils patch series: https://sourceware.org/pipermail/binutils/2022-December/124900.html

Seems it's for relaxing pcalau12i + addi.d into pcaddi, but I haven't looked further, and I'm not sure if indirect jumps are relaxed too.

[MaskRay]

I am on a trip until Dec 15 and will have some backlog to process...
I maintain lld/ELF and have implemented RISC-V linker relaxation. I'll have a strong opinion when someone attempts to add lld/ELF support, so I appreciate that I am CCed in the discussion.

Nevertheless, here are some early thoughts:

• R_LARCH_DELETE doesn't seem useful when R_LARCH_RELAX is present.
• https://sourceware.org/binutils/docs/as/Align.html "the maximum number of bytes that should be skipped by this alignment directive" is unfortunately not representable with R_RISCV_ALIGN
• Assembler behavior regarding label differences. See .option (no)?relax and label differences riscv-non-isa/riscv-asm-manual#80

6-bit in-place addition

This description is insufficient. It should specify which bits are modified.

[xen0n]

I am on a trip until Dec 15 and will have some backlog to process... I maintain lld/ELF and have implemented RISC-V linker relaxation. I'll have a strong opinion when someone attempts to add lld/ELF support, so I appreciate that I am CCed in the discussion.

Thank you very much, please take your time to relax (pun intended)! We definitely need to learn from RISC-V's lessons so we might be able to do better this time.

Nevertheless, here are some early thoughts:

* `R_LARCH_DELETE` doesn't seem useful when `R_LARCH_RELAX` is present.

Somewhat agreed. The relaxation model is again largely based on that of RISC-V but there's no R_RISCV_DELETE, so it may be indicative of its uselessness. (There is indeed R_MIPS_DELETE which makes me extremely wary though...)

6-bit in-place addition

This isn't useful. It should specify which bits are modified.

It seems to be something parallel to R_RISCV_{ADD,SUB}6 for DWARF processing. Do you mean the addition of such relocs is okay, only that the docs should be improved?

[MaskRay]

6-bit in-place addition

This isn't useful. It should specify which bits are modified.

It seems to be something parallel to R_RISCV_{ADD,SUB}6 for DWARF processing. Do you mean the addition of such relocs is okay, only that the docs should be improved?

I meant "This description is insufficient." Just updated the comment to be clearer.

Having add/sub relocation types is fine. The assembler behavior should be specified somewhere (hence the riscv-non-isa/riscv-asm-manual#80 link). The RISC-V documentation unfortunately doesn't make it clear and GNU as /LLVM MC behaviors are somewhat sub-par.

[xry111]

cc @MaskRay @xry111

Unfortunately I can't allocate time for this at present.

I don't understand linking process (especially relaxation) very well but I think Fangrui is an expert.

From the downstream perspective, I'd like to perform a full system rebuild with the Binutils relaxation patch, but I'm in a very bad mood now and my productivity will be likely very low.

One obvious question: RISC-V is disabling relaxation for their kernel. Will we need to do the same thing? cc @chenhuacai