[RFC] imgrel/imagerel operator from the clang integrated assembler and the Microsoft assembler

[Michael Matz]

Hello,

On Mon, 11 Nov 2024, Jan Beulich wrote:

> Seeing the full file is certainly useful. It raises the question though why
> __jsvml_dtanh_ha_data_internal would need accessing both as normal symbol
> and via @imgrel. To take an example, the original
> 
> 	vmovupd   xmm10, XMMWORD PTR [imagerel(__jsvml_dtanh_ha_data_internal)+2704+rdx+rcx]
> 
> could apparently be replaced by
> 
> 	vmovupd   xmm10, XMMWORD PTR [__jsvml_dtanh_ha_data_internal+2704+rcx]
> 
> (seeing that RDX holds __ImageBase). Question being why that's not done. It
> would even reduce the resulting binary size, for no longer requiring a SIB
> byte.

I think, as a matter of principle, all major (see below) relocation types 
should be associated with an assembly modifier.  If nothing else it will 
make writing testcases easier.  It being a matter of (my) principle I'd 
understand if that doesn't convince you :-)

In that case I may have something more convincing: make a (data) table of 
symbol references, with the assumption that they're used in instructions 
adding the image base.  (The advantage of such table: they won't need 
relocations at runtime).  I.e.:

.data
table:
.dc.a sym1@imgrel
.dc.a sym2@imgrel

Of course, there are alternative ways to avoid runtime relocations: make 
the symbol reference relative to something else that moves with the image 
base, e.g. the address of 'table' itself, or go full PC relative and do

.dc.a sym1 - .
.dc.a sym2 - .

.  But I don't think the assembler should prescribe how certain things can 
be encoded, and hence: if a file format defines certain relocation 
types that could conceivably be generally useful there should be a way to 
generate them via @ modifiers, without resorting to .reloc.

("Generally useful" is of course an ill-defined thing, but I'd think 
relocs that could be applied to data table entries would fit, whereas 
strange RISC relocs that split the top 23 bits of a value into six 
bitfields over 7 bytes would not fit :)  Other toolchains implementing 
certain modifiers for relocs might also be an indication of 'generally 
useful').


Ciao,
Michael.