NASM - The Netwide Assembler

NASM Forum => Programming with NASM => Topic started by: frp on August 04, 2013, 01:14:57 PM

Title: 64-bit OSX : 32-bit absolute addresses error
Post by: frp on August 04, 2013, 01:14:57 PM
Hello again,

I have another beginner question for you  :-[
The following code just replaces a character in the string Msg by a '*' char.

Code: [Select]
section .data
    Msg     db "Bonjour",0Ah
    MSGLEN  equ $-Msg

section .text
default rel
global _start
_start:
    mov al,'*'
    mov rsi,2        ; Just for the example. In fact, rsi can contain an integer between 0 and MSGLEN-2
    mov byte [Msg+rsi],al   ; ERROR

; Then print the message and exit

When I try to assemble (-f macho64), NASM (2.10.09) sends this error :

Code: [Select]
error: Mach-O 64-bit format does not support 32-bit absolute addresses
It works when I write instead
Code: [Select]
mov byte [Msg+2],al
Where am I wrong ?

Thanks for your help !
Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: Frank Kotler on August 04, 2013, 09:23:47 PM
Hi frp,

As you know, I'm clueless in 64-bit code, but "fools rush in..."

I can confirm that in "-f macho64", this generates an error. In "-f elf64" or "-f win64" it assembles silently. I suspect that you've discovered a bug. I don't know enough about "macho" to be sure. Unfortunately, I am unable to discover a workaround.

Anyone?

Best,
Frank

Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: Frank Kotler on August 04, 2013, 09:52:51 PM
Okay, possible workaround:
Code: [Select]
section .data
    Msg     db "Bonjour",0Ah
    MSGLEN  equ $-Msg

section .text
default rel
global _start
_start:
    mov al,'*'
    mov rsi, 2        ; Just for the example. In fact, rsi can contain an integer between 0 and MSGLEN-2
    mov rax, Msg
    mov byte [rax+rsi],al   ; okay?

; Then print the message and exit
I don't think you should have to do that. I still suspect a bug. But perhaps this will allow you to move forward(?).

Edit: Oops! My proposed workaround trashes al. Some other 64-bit register! You know what I meant. :)

Best,
Frank

Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: frp on August 05, 2013, 07:57:46 AM
Your solution works well ! And yes, this allows me to move forward  :) (but I'm sure I will have a lot of questions to post here in the future...)

Thank you very much, Frank.
Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: Frank Kotler on August 05, 2013, 10:07:06 PM
I passed this on to the development team, and got this from Nasm's chief maintainer:

-------------------------------------
default rel
global _start
_start:
    mov al,'*'
    mov byte [Msg+rsi],al   ; ERROR


The problem is that Msg here isn't PC-relative since it has an index.
This is presumably illegal in MachO64.  Instead he should:

   lea rdi,[Msg]
   mov [rdi+rsi],al

Note lea, not mov...

   -hpa
----------------------------------------

So apparently not a bug, but an oddity of the output format. I don't know wht "lea" is better than "mov" but I'll take his word for it.

Best,
Frank



Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: frp on August 06, 2013, 07:38:19 AM
Ok, I will use lea instead. I wonder if it was a good idea to begin with assembly on 64 bit OSX... but this is another question.

Thank you and thank the chief maintainer !
Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: dogman on August 06, 2013, 01:07:12 PM
I wonder if it was a good idea to begin with assembly on 64 bit OSX... but this is another question.

There are lots of platforms, lots of OS, and lots of assemblers. It really makes more sense to learn assembly language that will be useful on whatever hardware you own with whatever OS you run on it. If you run OSX for your daily driver then it's definitely a good idea to learn assembly language on it. You will become a better coder and learn more about your system doing that than by almost anything else you can think of.
Title: Re: 64-bit OSX : 32-bit absolute addresses error
Post by: frp on August 07, 2013, 11:53:51 AM
You must be right.

Thank you for your support  ;)