Problems with relocations for a custom ISA

[Xi Ruoyao]

On Tue, 2023-08-08 at 16:35 +0200, MegaIng via Binutils wrote:
> Our idea was that the user can use a simple pseudo instruction to 
> represent the
> entire process of loading a symbol (or any immediate for that matter).
> Maybe this is a misguided idea?

I'd say it's a bad idea.  A stack-based pseudo instruction reloc
approach had been used for LoongArch.  But the "pseudo instruction" has
never been implemented completely (doing so is just impossible unless
you rewrite the entire libbfd) so actually we could only handle some
special cases, and this approach caused much more trouble than the
benefit.  Now we've made these nasty things deprecated and we will
remove the support of them in a future Binutils release.

See https://github.com/loongson/LoongArch-Documentation/issues/9 for the
"much more trouble".

> It would have to be 3-4 RELOC_BITS_0_4, RELOC_BITS_5_9 
> RELOC_BITS_10_15 or something like that

Yes, now we use some traditional reloc types for LoongArch like them. 
And this approach works much better than the previous stack-based one. 
We now really wish we'd never tried the stack-based approach at all.

ELF allows 2^31-1 reloc types, so a larger reloc type set is not an
issue.

> but what about situations where nothing about the range of the value
> is known

You need to design some code models (sets of assumptions for the
ranges), like other BFD ports do.  If you really need the marginal
performance gain by exploiting the range limitations, you can also
implement linker relaxation.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University