[llvm] r335508 - Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code models"

[Reid Kleckner via llvm-commits]

On Thu, Jun 28, 2018 at 5:36 PM Lang Hames <lhames at gmail.com> wrote:

> Looks like this got re-reverted as it is breaking LLDB too. I would like
> to understand it better since we typically rely on Large/PIC for the code
> model in the JIT, and it has worked historically.
>

Well, before my change, large+pic wouldn't actually generate PIC code, the
code would contain hard-coded 64-bit immediate addresses. If we want to
store to a global, we'd generate code like:
  movabsq $global, %rax
  movl $42, (%rax)

So, we were really generating large+static code. Large+PIC basically wasn't
implemented.


> I restricted the MCJIT/eh-lg-pic.ll test to Linux, since the large PIC
>> code model is not implemented for MachO yet.
>
>
> What is the source for that claim? I thought the behavior of a relocation
> model/code-model pair was up to the platform to decide (though in practice
> if it's not well defined on MachO yet we may want to match Linux's
> behavior).
>

When I landed my change the first time, the Mac bots complained that
RuntimeDyldMachO didn't implement some relocations. I had to implement
relocations in RuntimeDyldELF to make this configuration work, but I didn't
do anything for MachO. It still needs to be implemented.

Why does LLDB want MCJIT to generate PIC code? Does it plan to relocate it?
Would it be possible to remove the call to
EngineBuilder::setRelocationModel and let LLVM decide on the correct models
for JITing based on the object file format?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180720/26ccffef/attachment.html>