<div dir="ltr">On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <span dir="ltr"><<a href="mailto:artagnon@gmail.com" target="_blank">artagnon@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span>Eli Friedman wrote:<br>
> On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
</span><span>>> We were just debugging a sporadic crash the other day, when we noticed<br>
>> that RIP-relative addressing was being used in a JumpTable, even when<br>
>> code and data were well over 4G apart. This is confusing, because we<br>
>> picked CodeModel::Large, and expected this to be taken care of. Isn't<br>
>> that what gcc would do given a Large CodeModel?<br>
><br>
><br>
> This sounds like a bug, but I can't reproduce it.  Testcase?<br>
<br>
</span>I've attached an example with a standard switch instruction, compiled<br>
with `llc -code-model=large`. It produces:<br>
<br>
movslq (%rax,%rdi,4), %rsi<br>
addq %rax, %rsi<br>
jmpq *%rsi<br></blockquote><div><br></div><div>Ah; I guess I actually should have spotted that.<br><br></div><div>See <a href="https://github.com/llvm-mirror/llvm/blob/f79c57a412cf8ba35884c1d4e011e07baad334d9/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L281" target="_blank">https://github.com/llvm-mirror/llvm/blob/f79c57a412cf8ba35884c1d4e011e07baad334d9/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L281</a> .  I think you can just force it to use EK_BlockAddress for the large code model.<br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<span><br>
>> Second, is it okay to<br>
>> silently fold into Reloc::PIC_ in this case and leave the user with<br>
>> sporadic crashes?<br>
><br>
><br>
> Large code model and PIC should be compatible.<br>
<br>
</span>Technically, yes. My understanding is that, instead of a cheap<br>
implicit $rip offset, you have to materialize the value in a register<br>
and do the `add`. I don't think LLVM is doing it correctly.<br>
<span><br>
>> Finally, can we bypass this limitation by simply<br>
>> appending "-elf" to our Target Triple, forcing ELF generation on all<br>
>> three platforms?<br>
><br>
><br>
> What exactly are you planning to do with an ELF object file on OS X?<br>
<br>
</span>I forgot to mention: we're JIT'ting. In any case, isOSDarwin() isn't<br>
influenced by an extra "-elf" to the target triple.<br></blockquote><div><br></div><div>Ah... I think it might have been possible to use ELF on OS X with MCJIT at some point, but it's not really supported in any case.<br><br></div><div>-Eli<br></div></div></div></div>