[llvm-dev] Quick question: How to BuildMI mov64mi32 arbitrary MMB address to memory

[K Jelesnianski via llvm-dev]

Dear Dr. Northover,

You've still got to access that symbol, and it's not obvious how a
> block that's moving around in memory could do that. The same arguments
> that it can't use %rip relative addressing for a local BB would seem
> to apply to any other entity.
>

Agreed, for now I will probably perform need to perform load-time analysis,
grab some info, and patch the binary to get around this. I have gone ahead
and begun implementing your proposed work around.

My question now is how would you create the BuildMI for the second assembly
instr (addq (LBB0_0 - func), %rax) you proposed? I know I can get the
global address of the MF we are currently in with
.addGlobalAddress(M->getNamedValue(MF.getName())) but how do we take that
and make an expression out of it. I am not sure the MBB object gives us any
way to  get its address and perform the given subtraction expression of
LBB0_0 - func.

So far I have the first instruction working:

    movq func at GOTPCREL(%rip), %rax
>

const Module *M = MF.getMMI().getModule();
/* movq func at GOTPCREL(%rip), %rax */
BuildMI(MBB, MBIt, DL, TII->get(X86::MOV64rm))
                      .addReg(X86::RAX)         //dest
                      .addReg(X86::RIP)         //base
                      .addImm(0x1)              //scale
                      .addReg(0x0)              //index
                      .addGlobalAddress(M->getNamedValue(MF.getName()))
//Disp
                      .addReg(0x0);             //seg


>     addq (.LBB0_0-func), %rax


 /* addq (.LBB0_0-func), %rax ???? */
BuildMI(MBB, MBIt, DL, TII->get(X86::ADD64ri32))
                      .addReg(X86:RAX)          //destination
                      .addReg(X86::RAX)         //base
                      .addImm(0x1)              //scale
                      .addReg(0x0)              //index
                   .addImm(<<<< I assume expression is related to
displacement and goes here >>>>>>>)
                      .addReg(0x0);             //segment

If I try to put a simple asm.s into llvm-mc -show-inst, it tells me to use
MCExpr, but I am not sure that is correct (shown below). There does exist
.addExpr but it only valid for MCInstBuilder, not
MachineInstrBuilder::BuildMI.
$ llvm-mc -show-inst asm.s
foo:
.LBB0_0:
    movq    2099957(%rip), %rax     # <MCInst #1810 MOV64rm
                                        #  <MCOperand Reg:35>
                                        #  <MCOperand Reg:41>
                                        #  <MCOperand Imm:1>
                                        #  <MCOperand Reg:0>
                                        #  <MCOperand Imm:2099957>
                                        #  <MCOperand Reg:0>>
    addq   (.LBB0_0  - foo) , %rax          # <MCInst #202 ADD64rm
                                        #  <MCOperand Reg:35>
                                        #  <MCOperand Reg:35>
                                        #  <MCOperand Reg:0>
                                        #  <MCOperand Imm:1>
                                        #  <MCOperand Reg:0>
                                        #  <MCOperand Expr:(.LBB0_0-foo)>
                                        #  <MCOperand Reg:0>>
    retq                            # <MCInst #2601 RETQ>


> Do I need to make these symbols for the trampoline BBs as an IR opt pass,
> can I get away with it using a MachineModule Pass to add the trampolines
> per module (file) (so far I have only created BasicBlock,
> MachineBasicBlock, and MachineFunction passes)??
> If you go that route you can probably add entries to the
> MachineConstantPool with a MachineModule pass. The same addressing
> concerns seem to apply though.
>

I actually forgot about this constraint, we already have experienced some
unintended side-effects when attempting to reference .rodata information
(e.g. printf printing garbage). So that is something to look fix in the
near future once this part is done. :)
Thanks again for your reply!

Sincerely,

K Jelesnianski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180924/48694343/attachment.html>