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

[Julian Waters]

In this case I think there might be a bit too much context - The Java Short
Vector Math Library is enormous and spans tens of thousands of lines of
assembly. An example of imagerel being used in it in the surrounding
context is
https://github.com/openjdk/jdk/blob/7d6a2f3740bf42652bdf05bb922d1f2b2ae60d6a/src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S#L98

Does the .reloc example rely on the instruction bytes being assembled into
a certain location (In this case, 4 bytes behind the current location)?
That might be rather brittle and easy to break if the instruction just so
happens to have the relocation itself in a different position as the example

best regards,
Julian


On Fri, Nov 8, 2024 at 6:21 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 08.11.2024 09:53, Julian Waters wrote:
> > There are times where it is needed to have the functionality of the
> > .rva directive as an operator on an expression. Take the following
> > handwritten assembly from the Java Short Vector Math Library:
> >
> > vmovupd   xmm4, XMMWORD PTR
> > [imagerel(__jsvml_dtanh_ha_data_internal)+2704+rdx+rcx]
> >
> > In this instance, .rva obviously cannot be used to obtain the virtual
> > address of the symbol for use in an instruction. Does GAS have any
> > undocumented specifier that can obtain the image relative offset of an
> > expression? If it does not, could we consider adding the @imgrel
> > operator from clang for this purpose?
>
> Just a few weeks ago I was pondering that, discarding the idea in the
> end. The reason for discarding it was that I couldn't think of a
> legitimate use case. The example you provide above looks similarly
> contrived, yet that may simply be because of lack of context. My
> basic question is: Why would code calculate any operand against the
> image base, rather than using proper symbol references?
>
> As to the (potential) "operator" itself: I don't really like @imgrel.
> It doesn't fit with the corresponding directive being .rva. Hence
> I'd prefer @rva, but I can of course see that for Clang compatibility
> we may want to also support its "operator".
>
> As to there being anything undocumented you can use instead: There's
> something documented really, but perhaps a little clumsy to use. A
> simple example would be (in AT&T syntax)
>
>         mov     $0, %eax
>         .reloc .-4, rva32, symbol
>
> Roughly your example above ought to translate to
>
>         {disp32} vmovupd   xmm4, [rdx+rcx]
>         .reloc .-4, rva32, __jsvml_dtanh_ha_data_internal+2704
>
> or maybe (as there are issues with addends, and I'm not sure whether
> they affect COFF as well)
>
>         vmovupd   xmm4, [rdx+rcx+2704]
>         .reloc .-4, rva32, __jsvml_dtanh_ha_data_internal
>
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20241108/2fbe3c29/attachment.htm>