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

[K Jelesnianski via llvm-dev]

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>