CREL relocation table contains addends even for RELA-type psABIs

[rui314]

It looks like CREL relocation tables contain addends even for ARM32 and i386. This deviates from their psABIs, where addends are typically stored at relocated places.

For REL-type psABIs, can LLVM store addends at relocated places instead of in CREL tables?

I see two reasons for doing so:

1. It aligns more closely with the baseline psABI and simplifies support for other tools that expect addends to be at relocated places rather than in the relocation table. This is our motivation (crel fails on i686 and armv7l since commit bf1ec5ac rui314/mold#1430).
2. Since CREL was designed to save disk space, storing addends in CREL isn't ideal for these targets. Eliminating addends could save more bytes per relocation.

[MaskRay]

Thank you for your interest in CREL! While implicit addends work well for dynamic relocations, I don’t find them as beneficial for static relocations. I touched on this in my post:

By enabling the assembler to leverage implicit addends, we can further reduce size by compressing most relocations into a single byte (typically 0x04, offset+=1<<3). That said, this could negatively impact compression when using --compress-debug-sections=zstd. For that reason, I’d suggest avoiding implicit addends in this case.

I conducted some experiments with CREL static relocations using implicit addends (there is a stale branch, more updated one is lost: https://github.com/MaskRay/llvm-project/commits/demo-crel-rela-only-for-code/), but I recall that compressed debug sections might actually grow larger. There could be minor savings in code and data sections, though, overall, I think it's a poor fit. Implicit addend static relocations are not worth the effort of adapting assemblers, linkers, and dumpers.

This deviates from their psABIs, where addends are typically stored at relocated places.

While implementations might be REL only, aaelf32 explicitly supports RELA relocations.
i386 documentation seems to lack explicit mention of REL or RELA.

Anyhow, I believe that the toolchains for these architectures adopted REL primarily for space efficiency, a benefit that diminishes with the transition to CREL.
Adhering to REL unnecessarily limits potential optimizations. In fact, I recall instances in AArch32 where RELA would have enabled more efficient code sequences, although the specifics escape me at the moment... i386 work is almost retro computing nowadays..

[rui314]

I think my argument is that you are making CREL more than just a compact relocation table format; you're effectively introducing a significant psABI change by attempting to require all psABIS to support not only REL but also RELA. Is that really necessary? In my view, it’s better to maintain the idea that CREL is simply a compact relocation format that works exactly the same way as existing ones, rather than combining two independent changes into one. Maybe ELF shouldn't have had two different relocation table formats in the first place—perhaps REL should never have been invented—but unfortunately, we're stuck with it forever. In my opinion, trying to "fix" it with CREL isn't a wise way to use resources.

[MaskRay]

As noted, psABIs do not need to specify whether RELA is used. If CREL relied solely on explicit addends, it wouldn’t impose any restriction.

However, supporting CREL static relocations with implicit addends would actually cause more burden to assemblers, binary utilities, and linkers that support both REL/RELA for one single architecture.
Since assemblers and binary utilities already need to support RELA, and once RELA works for one architecture it generally works across others.
Adding REL support would require extra effort.

I reviewed mold, and it seems that for each architecture, only one of REL or RELA is supported (static constexpr bool is_rela = true;).
While this saves many runtime dispatches and works pretty well in practice both GNU and LLVM, I could see how this make adoption of CREL explicit addends more difficult.

That said, we might not need to worry about whether AArch32 or i386 users want to switch to CREL. These architectures aren’t typically used in large projects, so the size of build-time relocations is unlikely to be a concern for users.

(The i386 is largely relegated to retro-computing these days. I once brought up something about R_386_PC32, and H.J. responded firmly, saying i386 is legacy and best left alone.
)

[rui314]

Multi-platform apps tend to use the same command line options to build (that's what Chromium does), so even though CREL's benefit would be limited on ARM32, we would still need to support it on ARM32. Since REL is effectively the standard on ARM32, many tools would assume so, creating obstacles to the smooth adoption of the CREL extension.

I don't think all implementations supporting CREL need to support reading implicit addends from sections. Instead, could you require the assembler to write addends to both CREL and the relocated locations for psABIs that use REL-type relocations? It may not be the most elegant solution to the problem, but from a practical standpoint, it would eliminate a major roadblock for many tools.

[MaskRay]

Instead, could you require the assembler to write addends to both CREL and the relocated locations for psABIs that use REL-type relocations? It may not be the most elegant solution to the problem, but from a practical standpoint, it would eliminate a major roadblock for many tools.

Requiring this could complicate assembler design and testing, while also diverging from standard RELA behavior (zero in the operand).
Do we have any evidence that supporting RELA actually poses challenges for a tool that already handles at least one other RELA target?
In my experience, the opposite is true: for a tool already supporting CREL with explicit addends, adding support for implicit addends would create more of a burden.

Yeah, I strongly believe we shouldn’t burden assemblers with yet another variant involving implicit addends.