[LLVMdev] fatal error: error in backend: 32-bit absolute addressing is not supported in 64-bit mode
Tim Northover
t.p.northover at gmail.com
Thu Jun 11 09:19:47 PDT 2015
Hi Jack,
On 11 June 2015 at 08:21, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:
> While building FSF gcc 5.1 against Apple's public Xcode 7 beta's
> new clang-based assembler, I ran into rejected assembly instructions
> during the -m32 multilb build of libjava.
The diagnostics here don't seem to have changed in Clang, going back
to even early Xcode 6.
> natArray.s:1110:2: error: ambiguous instructions require an explicit
> suffix (could be 'filds', or 'fildl')
> fild 8(%esi,%edi,2)
This seems reasonable to me. It seems GCC arbitrarily chooses "filds",
but there's no grand logic behind that decision. I prefer requiring an
explicit disambiguator.
> clang -cc1as: fatal error: error in backend: 32-bit absolute
> addressing is not supported in 64-bit mode
Technically, I believe MachO could support such a relocation. But it's
never one you'd actually want to use because PAGEZERO occupies the low
32-bits of the address space as a guard against null pointer accesses.
So I think this is probably better than the alternative too.
I'd probably suggest making the test use "filds (%ebp)", which should
assemble in both 32-bit and 64-bit modes and sidesteps the whole
relocation issue. "filds mem(%rip)" would be a sound 64-bit
instruction closer to the original, but wouldn't assemble on 32-bit.
Cheers.
Tim.
More information about the llvm-dev
mailing list