NASM - The Netwide Assembler

NASM Forum => Programming with NASM => Topic started by: rouki on July 12, 2014, 04:20:44 PM

Title: Mach-O 64-bit format does not support 32-bit absolute addresses
Post by: rouki on July 12, 2014, 04:20:44 PM

Hey guys :) The aforementioned error (At the title) occurs in the following code (Compiling in OS X - mach-o 64)

arr: dd 0x0FFFFFFF, 0x03020100, 0x07060504, 0x0B0A0908

movdqa xmm5, oword[arr]

What's the reason?
Any suggestions?

thanks in advance

Title: Re: Mach-O 64-bit format does not support 32-bit absolute addresses
Post by: gammac on July 12, 2014, 05:10:42 PM

I don't know, but I know that movdqa needs an aligned address. Therefore, I think arr must be aligned at 16.

Title: Re: Mach-O 64-bit format does not support 32-bit absolute addresses
Post by: Frank Kotler on July 12, 2014, 05:40:21 PM

I can confirm that this happens. Assembling as "-f elf64" or "-f win64" works fine. Using "default rel" or "movdqa xmm5, oword [rel arr]" works fine. I don't know why "-f macho64" thinks this is a 32-bit address. I suspect a bug, but I don't really know what "-f macho64" is "supposed" to do. Can you live with "rel"?

I would "expect" that a misaligned address would assemble without error, but would crash when you run it.

Thanks for the feedback!

Best,
Frank

Title: Re: Mach-O 64-bit format does not support 32-bit absolute addresses
Post by: Cyrill Gorcunov on July 13, 2014, 09:50:48 AM

Indeed looks like a MachO64 bug, but can't say for sure since I'm not really familiar with this output format. Once time permit I'll take a look but better guys file a bug please.

Title: Re: Mach-O 64-bit format does not support 32-bit absolute addresses
Post by: Keith Kanios on September 20, 2014, 04:46:35 PM

For any issues of "Mach-O 64-bit format does not support 32-bit absolute addresses", use DEFAULT REL at the top of your source code.

Also, that message may cause general troubleshooting confusion as 64-bit Mach-O really lacks support for absolute 32-bit symbols, as you can easily use 32-bit immediate numbers (e.g. 0x000B8000) without issue per the x86-64 instruction set.

Offhand, I think defaulting to REL whenever macho64 is used would probably be the real fix in this case.