[llvm-dev] PIC preferred too strongly, even at CodeModel::Large?

[Eli Friedman via llvm-dev]

On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> We were just debugging a sporadic crash the other day, when we noticed
> that RIP-relative addressing was being used in a JumpTable, even when
> code and data were well over 4G apart. This is confusing, because we
> picked CodeModel::Large, and expected this to be taken care of. Isn't
> that what gcc would do given a Large CodeModel?
>

This sounds like a bug, but I can't reproduce it.  Testcase?


> The default Relocation Model, Reloc::Default, folds into Reloc::PIC_
> in most cases. However, if we explicitly specify Reloc::Static, our
> program should work on all platforms except Darwin:
>
>   // If we are on Darwin, disallow static relocation model in X86-64 mode,
> since
>   // the Mach-O file format doesn't support it.
>   if (RM == Reloc::Static && TT.isOSDarwin() && is64Bit)
>     RM = Reloc::PIC_;
>
> (from X86MCTargetDesc.cpp)
>
> First, is the Mach-O limitation still there?


Yes, the Mach-O limitation still exists as far as I know.

Second, is it okay to
> silently fold into Reloc::PIC_ in this case and leave the user with
> sporadic crashes?


Large code model and PIC should be compatible.

Finally, can we bypass this limitation by simply
> appending "-elf" to our Target Triple, forcing ELF generation on all
> three platforms?
>

What exactly are you planning to do with an ELF object file on OS X?

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/445c0b92/attachment.html>