From: <sp...@dy...> - 2007-04-15 22:21:06
|
> sp...@dy... wrote: >> >> How is this incorrect? Everything that calls upon RIP-relative >> addressing >> *seems* to be relative to the respective instruction... just as HPA >> illustrated above. >> > > Right, but that's not what is realistically denoted by [rip+<something>]. > > Consider the following example: > > bits 64 > > foo equ 1234h > > times 16 nop > > ; This should assemble to [rip+1234h] > r1: mov rax,[rip+foo] > > ; This should assemble to [rip+1234h-r3] > ;r2: mov rax,[rip:foo] > r3: > > > The first instruction should logically assemble to > "48 8b 05 34 12 00 00" regardless of it's position in the code, but it > doesn't. 1234h here is the *offset* from RIP, not the address referred > to. > > The second instruction, however (commented out) should have its offset > field vary depending on its own position in the code; it's *referring to > address 1234h using RIP-relative addressing*, which is a different > operation entirely. OK, I did find a solution that is rather elegant/simple... only two lines of code... check out the new assemble.c that I've uploaded to CVS :) I checked this new version against a fusion of your example and mine... seems to work as advertised. Let me know if any other exceptions show up ;) > As I said, in YASM the first is written [rip+foo] and the second is > written [foo wrt rip], which is bulky as all hell; hence the suggestion > for [rip:foo]. I think nasm64developer's in-house version of NASM used > [rip foo], which I personally isn't very fond of. > Yeah, I'm a stickler for consistency myself *cough* [ds/es/fs/gs:foo] *cough* :P Let me know if you want to keep it simple (e.g. [rip:SYMB/IMMEDIATE]) or make the distinction (e.g. [rip:SYMB] and [rip+/-IMMEDIATE]). The simple version can apply for immediate values as well (e.g. [rip:-0x1234])... so my vote is obviously for that if at all feasible :) |