llvm dev - Sep 2018 - Quick question: How to BuildMI mov64mi32 arbitrary MMB address to memory

Dear Mr. Northover,

Thank you for the quick reply. You are correct about the address-mode
operands :) . I guess an important detail left out was that the basic block
(call it A) that wants to calculate the address of the target stationary
trampoline basic block (call it B) will be moved around in memory during
run-time. Our earlier solution, before the feature was implemented to move
around (A) is exactly as you explained using the following with a scratch
reg:

$ bin/llc -relocation-model=pic simple.ll -o -
> [...]
>         leaq    .Ltmp0(%rip), %rax
>         movq    %rax, (%rdi)
>
We now run into the problem that with this feature enabled, if we try to
perform LEA backwards to the trampoline, after A has been moved the %rip
relative offset that was put in by LLVM is no longer valid. Also if we
perform LEA forwards to the target address in A that trampoline B is
supposed to trampoline us too, that address will also be invalidated once A
has been moved. Thus calculating forwards is most likely impossible. This
leaves calculating LEA backwards to the trampoline BB (B) since we know
that the trampoline BB will remain stationary throughout execution. That is
why I would "like" to somehow store (B)'s address.

I am looking for a work around to accommodate this feature. I have never
attempted to make my own section/symbols using LLVM, but I assume this is
the route I should take? Pairing each trampoline BB to a symbol should make
it visible and this MOVQ instruction I want possible?
With that approach, my questions are:
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)??
Do I need to make a separate custom section for these trampolines symbols,
or can I just add them to the .text section?

Thanks again for your reply.
Sincerely,

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

I also confirm I am building my executables and libraries with "-fPIC
-pie"
CFLAGS to be able to take advantage of ASLR.

On Sat, Sep 22, 2018 at 5:20 PM K Jelesnianski <kjski at vt.edu> wrote:
> Dear Mr. Northover,
>
> Thank you for the quick reply. You are correct about the address-mode
> operands :) . I guess an important detail left out was that the basic block
> (call it A) that wants to calculate the address of the target stationary
> trampoline basic block (call it B) will be moved around in memory during
> run-time. Our earlier solution, before the feature was implemented to move
> around (A) is exactly as you explained using the following with a scratch
> reg:
>
> $ bin/llc -relocation-model=pic simple.ll -o -
>> [...]
>>         leaq    .Ltmp0(%rip), %rax
>>         movq    %rax, (%rdi)
>>
>
> We now run into the problem that with this feature enabled, if we try to
> perform LEA backwards to the trampoline, after A has been moved the %rip
> relative offset that was put in by LLVM is no longer valid. Also if we
> perform LEA forwards to the target address in A that trampoline B is
> supposed to trampoline us too, that address will also be invalidated once A
> has been moved. Thus calculating forwards is most likely impossible. This
> leaves calculating LEA backwards to the trampoline BB (B) since we know
> that the trampoline BB will remain stationary throughout execution. That is
> why I would "like" to somehow store (B)'s address.
>
> I am looking for a work around to accommodate this feature. I have never
> attempted to make my own section/symbols using LLVM, but I assume this is
> the route I should take? Pairing each trampoline BB to a symbol should make
> it visible and this MOVQ instruction I want possible?
> With that approach, my questions are:
> 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)??
> Do I need to make a separate custom section for these trampolines symbols,
> or can I just add them to the .text section?
>
> Thanks again for your reply.
> Sincerely,
>
> K Jelesnianski
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180922/73a78757/attachment.html>

Hi,

On Sat, 22 Sep 2018 at 22:21, K Jelesnianski <kjski at vt.edu>
wrote:
> I am looking for a work around to accommodate this feature. I have never
attempted to make my own section/symbols using LLVM, but I assume this is the
route I should take? Pairing each trampoline BB to a symbol should make it
visible and this MOVQ instruction I want possible?
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.

If you have a solution for that problem, an alternative to creating
entirely new symbols would be to reference the stationary BB relative
to the function's entry-point. In assembly something like:

    movq func at GOTPCREL(%rip), %rax
    addq (.LBB0_0-func), %rax
> 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.

Cheers.

Tim.

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>