Ticket #21 (closed defect: invalid)

Opened 5 years ago

Last modified 2 years ago

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

Reported by: phillim2 Assigned to: peter@tortall.net
Priority: P2 Milestone: 0.4.0
Component: Architecture: x86 Version: other
Severity: normal Keywords:
Cc:

Description 

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.

Attachments

Change History

11/15/03 20:38:40 changed by 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.

11/16/03 22:47:50 changed by 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.

11/17/03 20:37:56 changed by phillim2

  • status changed from new to resolved.
  • resolution set to invalid.
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.

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