Question about: "Warning: Absolute address can not be RIP-relative"

[soulvomit]

Background:
So I recently began porting my A* C++ implementation to Assembly using NASM. The C++ version is currently very fast and leaves a light memory footprint, but being the speed demon that I am, I decided to go with an Assembly implementation, to see if I could squeeze out a couple more nano seconds from the algorithm.

Problem/Question:

Code: [Select]

mov rbx, [Node.BaseCost]
NASM will assemble this, but LD (GNU Linker) won't link it giving an error;

Node.o64:Node.asm:(.text+0x4): relocation truncated to fit: R_X86_64_32 against `.data'

This can be remedied by doing;

Code: [Select]

mov rbx, Node.BaseCost
mov rbx, [rbx]
But that is obviously slower and more cumbersome to do. The solution, it seems is to use RIP-relative addressing;

Code: [Select]

mov rbx, [rel Node.BaseCost]
When I do this the the GNU Linker links with no errors, and the code works as intended, but NASM gives me a warning when assembling;

Node.asm:57: warning: absolute address can not be RIP-relative

So my question is why does the warning occur, and can I safely ignore it considering my code works as intended?

Platform:
Windows 10, Cygwin64

Assembling/Linking + Options:

nasm64 -Wall -g -F cv8 -f win64 Node.asm -o Node.o64 -l Node.lst
ld -e main Node.o64 -Map=Node.map -o NodeTest.exe

Thank you.

[soulvomit]

Okay so I found the solution through some trail and error. It was to apply relative-rip addressing to the data segment. Not gonna post the whole code (it is effing long at the moment), but here is a working snippet (might be useful to someone else):

Platform: Win10/Cygwin64

Code: [Select]

[BITS 64]
[GLOBAL main]
[SECTION .text]

main:
        mov rbx, [Node.BaseCost]
        .end
                jmp .end

[BITS 64]
[SECTION .data]
[DEFAULT REL]
align 8
Node:
.BaseCost:        dq   1


Assemble/Link:

nasm64 -Wall -g -F cv8 -f win64 Node.asm -o Node.o64 -l Node.lst
ld -e main Node.o64 -Map=Node.map -o NodeTest.exe

This works for me and is both warning and error free using only the tools Cygwin64 provide.

Thank you.

[Frank Kotler]

Thank you, soulvomit. Welcome to the forum.

Best,
Frank

[ig]

So is this a bug in the latest build of NASM, or am I overlooking something obvious?
I also started to get those warnings with v2.12.02. When I compile the following file

Code: [Select]

bits 64
default rel

section .text
test:  lea     rax, [table]

section .rdata
table:  DD 0x00000000
using NASM 2.12.02 and the commandline

Code: [Select]

nasm.exe test.asm -o test.obj -g -Ox -s -DWIN_ABI -f win64I get the warning

Code: [Select]

test.asm:5: warning: absolute address can not be RIP-relative
The warning cannot be suppressed even with the -w-all switch.
When I use NASM 2.12.01 on the same file, there is no warning (and the code generated to test.obj is identical in both cases).

However, when I swap the order of the sections, i.e. when I compile

Code: [Select]

bits 64
default rel

section .rdata
table:  DD 0x00000000

section .text
test:  lea     rax, [table]the warning disappears even from NASM 2.12.02.

Thanks.

[soulvomit]

Hi,

In my experience "relative rip addressing" should be applied only to the data segments. When you have your code segment on top, it seems "relative rip addressing" gets applied only to the code segment. And vice versa, when you have the data segment on top (which should be correct, hence no error). I would advise you to be more expressive about where you apply relative addressing, like:

Code: [Select]

bits 64

section .text
test:  lea     rax, [table]

section .rdata
default rel
table:  DD 0x00000000

section .data
default rel
other_table:  DD 0x00000000


[G Tucker]

Addressing mode refers to how the instruction is encoded so seems logical to put in .text section.  Lots of existing code does it this way.  What if you wanted to address the same data in two different ways?

Nasm manual sec 6.2 just says that "default rel/abs" turns on and off but the following with "default rel" in both .text and data also emits warnings:

bits 64
section .text
default rel
test:     lea     rax,

section .rdata default rel table:    DD 0x00000000 ; nasm -f elf64 file.asm

[soulvomit]

Addressing mode refers to how the instruction is encoded so seems logical to put in .text section.  Lots of existing code does it this way.  What if you wanted to address the same data in two different ways?

Nasm manual sec 6.2 just says that "default rel/abs" turns on and off but the following with "default rel" in both .text and data also emits warnings:

bits 64
section .text
default rel
test:     lea     rax,

section .rdata default rel table:    DD 0x00000000 ; nasm -f elf64 file.asm

I don't know the proper, logical or documented way of applying/switching addressing mode. I only know what works for me in my project, through trail and error. Your example will work, error/warning free, if you seperate the .text section and .rdata section in to different source files. At least when linking with cygwin LD.

[soulvomit]

Double post.

[wild.pie]

i was browsing nasm code randomly today and happened to land on this page. did a quick search, it seems nasm sets op.segment to NO_SEG when initializes forward reference type of memory operands (somewhere in parser.c). later in process_ea(), where it generates mod/rm, sib, and displacements for memory accesses, it performs a safety check to prevent using ip-relative mode to reference absolute address. what is an absolute address? an address without segment/section, or, op.segment == NO_SEG.

so i guess this is a nasm bug. it seems it doesn't differentiate forward references and abs addressing.

however, i'm not expert on nasm or its code. i could be very wrong. it's just my guess. hope it helps.