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

[Jan Beulich]

On 12.11.2024 17:57, Michael Matz wrote:
> 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 :-)

I actually agree with this principle, which is why (as said) a few weeks
ago I did consider adding support. Yet as per your below "generally useful"
the outcome was that I concluded this wouldn't be "generally useful". Now
that while replying to Julian I finally realized a case where it would
indeed be useful, the picture changes.

Just for completeness' sake, ...

> 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

... this would work only for 32-bit binaries afaict: There's no 64-bit
image-relative relocation for x86-64 COFF/PE, according to all I know.
Plus for image-relative data we already have a data directive (which
Julian also mentioned in his original mail): ".rva".

By following said principle we should then also allow the same for ELF
(where suitable relocations exist). Although it looks like x86
R_*_RELATIVE relocs are oddly defined (no symbol involved), and more
generally R_*_RELATIVE appear to be deemed dynamic relocs only.

> 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').

Actually I would consider insn-only relocations useful to have, too. And
Arm, Arm64, and RISC-V actually have such pseudo-operators, to take a
couple of examples. The set they support may not be "complete", though.

Jan