[Nasm-bugs] [Bug 3392468] NASM 2.13.02 breaks macho64 .data fixups

[no-reply at bugzilla-nasm.gorcunov.org]

https://bugzilla.nasm.us/show_bug.cgi?id=3392468

--- Comment #6 from Michael Petch <mpetch at capp-sysware.com> ---
I can confirm this building on High Sierra using 2.13.02 and 2.14rc0-20180226
(built with ./configure) produces incorrect addresses when linked. This occurs
when the memory references were absolute and not RIP relative. Modifying code
to be RIP relative seems to work fine. The following code demonstrates the
problem:

%macro printString 2
    mov     rax, 0x2000004 ; write
    mov     rdi, 1 ; stdout
    mov     rsi, %1
    mov     rdx, %2
    syscall
%endmacro

global _start

section .text
_start:
    printString str1,str1.len
    printString str2,str2.len

    mov     rax, 0x2000001 ; exit
    mov     rdi, 0
    syscall


section .data

str1:   db      "Hello,",10
.len:  equ       $ - str1

str2:   db      "world",10
.len:  equ       $ - str2

This code should simply print out:

    Hello,
    world

on stdoout. It only prints:

    Hello,

Plus a number of null bytes where "world" was suppose to be.

I build this code with:

    nasm -f macho64 test.asm
    ld -macosx_version_min 10.12.0 -lSystem -o test test.o -e _start

I am attaching an objdump (with code and relocations) of both the object file
and the final program. The code for the fully linked program contains the wrong
offsets for the str2 label. Str2 looks like:

0000000000002007 <str2>:
    2007:       77 6f                   ja     2078 <str2+0x71>
    2009:       72 6c                   jb     2077 <str2+0x70>
    200b:       64                      fs
    200c:       0a                      .byte 0xa

The instruction that puts the address of str2 into a register looked like:

    1fe3:       48 be 0e 20 00 00 00    movabs $0x200e,%rsi

The problem is that str2 is at 0x2007 but the relocated value in the move is
0x200e which is after the string. This is why the code prints NUL characters
rather than "world".

I can confirm this wasn't a problem in 2.13.01. The alternative fix is to
modify the code to use RIP relative addressing rather than absolute. The
generated code looks fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.