[LLVMbugs] [Bug 8684] [MC assembler] X86-16 not supported

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=8684

dwmw2 at infradead.org <dwmw2 at infradead.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from dwmw2 at infradead.org <dwmw2 at infradead.org> ---
This should all now be working.

Two things to bear in mind:

Firstly, we do not support the explicit 'data32' and 'addr32' prefixes that GNU
as supports (neither do we support 'data16 or 'addr16' in 32-bit mode). That
would be the subject of a separate feature request.

In practice, I cannot think of a single case where an explicit 'data32' is
needed because the operand size can always be implicit in the mnemonic suffix.
Some people like to write 'data32 lgdt', where 'lgdtl' would sufficed, for
example.

For the GNU toolchain, 'addr32' *is* sometimes needed because even with an
immediate address larger than 64KiB it will still refuse to use 32-bit
addressing modes unless explicitly told to do so. LLVM does not suffer that
idiocy at the moment, and 'movl $0, 0xf0000000' will actually do the sane
thing. So for LLVM you can mostly just drop the 'addr32' prefixes that the GNU
toolchain requires.

Secondly, the code we generate is a little larger than the code generated by
GNU as — mostly because we're so quick to use 32-bit addresses. We use 32-bit
addressing modes whenever the address is not an immediate and below 64KiB. So
*all* symbol references which require relocs will be 32-bit. 


Then of course there are unrelated bugs like bug 18303 which will hurt you if
you change modes within a single asm file, and bug 3997 which is the only
remaining reason why the Linux kernel's 16-bit startup code doesn't build
correctly with 'clang -m16' as of today.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140123/ac73f128/attachment.html>