double relative addressing failing in macros. (x86_64) (cvs yasm 11/15/03)

[phillim2@…]

Porting nasm code to x86_64, trying to create PIC obj you need to add wrt rip or
+rip in relative addressing. A macro is being called with a static var as one of
its parameters. In the macro the following is coded: movqda xmm1, [%2+16], where
%2 is the passed in static var. To create PIC code for x86_64 this needs to be
relative to rip. The only combination of wrt and + that even compiles is movqda
xmm1, [%2+16+rip]. The created offset is *majorly* wrong. Trying to link this
file into a shared lib barfs big time. 
Work around for the moment is to lea rax,[%2 wrt rip] and then use rax+16 in the
movqda instruction.

[phillim2@…]

OK, so not majorly wrong, but the address is 4 bytes off. I just compared the
output from the [%2+16+rip] version to the address used in the lea rax, [%2 wrt
rip]. The [%2+16+rip] version is calculated as 4 bytes more than the lea one. 

[peter@…]

Try [(%2+16) wrt rip].

+ and WRT mean two different things when talking about rip-relative addressing.
 + means use the value given as a relative offset from rip.  WRT means treat the
value given as an absolute address, but make it RIP-relative when generating the
code.

The reason [%2+16 wrt rip] gives an error is because WRT is higher precedence
than + in expressions.

Give this a try and let us know.  We really should work on better documentation
for this feature.

[phillim2@…]

Yep, that did the trick, thanks. (You know, I thought I'd tried every
combination of (),+,wrt to find a working solution - obviously not)

Interesting, the +rip does actually assemble under yasm, but it creates the
wrong symbol type in the elf header, X86_64_32, using wrt rip creates
X86_64_PC32. ld doesn't know what to do with the first, it needs the second to
build shared libs. 

If I get a chance when I'm done porting the code and ironing out the bugs, I'll
try to write a small piece on porting nasm 32bit -> yasm 64bit x86_64 code.