[llvm-dev] MASM & RIP-relative addressing

[Eric Astor via llvm-dev]

Apologies - I apparently remembered part of the issue incorrectly, so this
ended up quite confusing. The problem comes when referencing labels in a
different section of the binary. To clarify, if I assemble the code:

.data
foo BYTE 5
.code
mov eax, foo

with Microsoft's ml64.exe, it emits an object file disassembling to:

       0:       8b 05 00 00 00 00       mov     eax, dword ptr [rip]
                000000000000000b:  IMAGE_REL_AMD64_REL32        foo

On the other hand, if I use my current local draft of llvm-ml, I get a
different result. I actually get the same result as I do for llvm-mc, using
the corresponding code:

.data
foo:
.byte 5
.text
.intel_syntax
mov eax, foo

Either way, LLVM emits an object file with disassembly (and relocation) as
follows:

       0:       8b 04 25 00 00 00 00    mov     eax, dword ptr [0]
                0000000000000003:  IMAGE_REL_AMD64_ADDR32       foo

To replicate the results from ml64.exe with LLVM, I instead need to use

mov eax, [foo + rip]

in place of mov eax, foo. At least when building with llvm-ml, we need to
mimic ml.exe's approach; a reference to a symbol in another section should
use the relative addressing mode.

My first attempt to fix this was very clumsy - when in MASM mode, I forced
all expressions without a base register to presume RIP. Unfortunately, that
breaks any attempt to use "jcc", since it turns label references into
absolute memory references with a base register (and the "jcc" family
doesn't accept absolute memory operands). Any suggestions for how I can fix
the issue described here without breaking "jcc"?

On Tue, Jan 21, 2020 at 3:43 PM Eli Friedman <efriedma at quicinc.com> wrote:

> All immediate jump instructions on x86 (call/jmp/jcc) have a relative
> offset operand.  The destination is, in some sense, “rip-relative”, but we
> don’t represent it like that in LLVM.  If you look at the TableGen
> descriptions, jumps use brtarget32, and calls use i32imm_pcrel.  In both
> Microsoft and GNU assembly syntax, this is something like “call baz”.
>
>
>
> “call”/”jmp” also have a register/memory form, for indirect calls.  In
> 64-bit, this allows rip-relative references, to call a function pointer
> stored in a global variable.  In Microsoft assembly syntax, this is “call
> QWORD PTR baz”. In GNU assembly syntax, this is “call *baz(%rip)”.
>
>
>
> For 64-bit x86, any reference to a global has to be a rip-relative address
> (since all 64-bit programs are position-independent), but on 32-bit x86,
> it’s also possible to refer to the address of a variable using something
> like “add eax, OFFSET baz”.
>
>
>
> For globals which are explicitly labeled “PTR” or “OFFSET”, the correct
> representation should be unambiguous, and it should be easy to print
> appropriate error messages.  For other cases, I’m not sure what the
> inference rules are.  It might vary depending on the opcode.
>
>
>
> -Eli
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Eric
> Astor via llvm-dev
> *Sent:* Monday, January 20, 2020 6:26 PM
> *To:* LLVM-dev <llvm-dev at lists.llvm.org>
> *Subject:* [EXT] [llvm-dev] MASM & RIP-relative addressing
>
>
>
> Hi all,
>
>
>
> Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is
> in enabling MASM's convention that (unless specified) all memory location
> references should be RIP-relative. Without it, we emit the wrong
> instructions for "call", "jmp", etc., and anything we build fails at the
> linking stage.
>
>
>
> My best attempt at this so far is a small patch to X86AsmParser.cpp - just
> taking any Intel expression with no specified base register and switching
> it to use RIP - and this works alright. There's at least one exception: it
> breaks the "jcc" instructions, at least "jcc <label>". The issue seems to
> be that the "jcc" family exclusively takes a relative offset, never an
> absolute reference... so adding a base register causes the operand not to
> match. ("jcc" is always RIP-relative anyway.)
>
>
>
> I'm not very familiar with the operand-matching logic, and am still pretty
> new to LLVM as a whole. Are there more X86 instructions this will interact
> badly with? Any thoughts on how this could be handled better?
>
>
>
> If this is mostly a valid approach, might there be a way to change the
> operand type of "jcc" to accept offset(base) operands, as long as base ==
> X86::RIP, then ignore the RIP bit?
>
>
>
> Thanks,
>
> - Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/444f0f07/attachment.html>