Also added unit tests which uses MCJIT to create position independent code.
Also, I and @rafael have ideas on how to change the reloc model to include PIE (see https://reviews.llvm.org/D21100#455440). Not sure when it's gonna happen, but you may want to consider that it could change in the future (and you don't want to rely on it). LLVM doesn't provide stability guarantees about APIs anyway IIRC (cc: @echristo)
The real problem is with memory reservation for position independent code, which occurs because RuntimeDyld doesn't calculate size of .got section.
Memory reservation occurs when virtual method needsToReserveAllocationSpace() of memory manager returns true. Currently jitting position
independent code and using memory reservation at the same time causes undefined behavior.
I have patch addressing this issue, but it is blocked by this review:
The source file MCJITCAPITest.cpp already has test for JIT memory reservation (see TestReserveSectionMemoryManager), so to test the fix for a "PIC/reservation" problem I would need to
add just few lines of code. But I need to be able to set relocation model from C API to do this.
So what I actually plan to do is to land this patch + D28571, and after that submit a review for problem described above.
This patch makes it very easy to write a test case for that problem.
Sadly, many people are using the C API in foreign languages (as in not C, not German or French).
I know there is no promise to keep the OrcJIT API stable at this stage, so maybe that's ok, but it's a bit unfortunate that this ends up being in the ExecutionEngine rather than some Orc specific header. Maybe deproting Orc specific declaration from there to some Orc specific header would be better.
Why not use Reloc::Default ?
I've been thinking that Reloc::Default should probably not default to static every time, because more and more linux distro use PIE by default on amd64. Maybe default should become whatever the target uses as default.
What exactly declaration are you talking about?
As far as I know relocation model is not something specific to ORC. At least I used legacy MCJIT API with PIC long time go, but I used C++ API (llvm/ExecutionEngine.h). The fact one can't use PIC from C API looks like as a limitation of C API to me.
Just because there is no such enumeration value. See llvm/Support/CodeGen.h
The C API has stricter backward compatibility constraints than the regular C++ API, because it is used from other language. These users won't get any error, just weird crash because the structure layout do not match anymore.
Is MCJIT going away at some point ? If so I'd just duplicate the struct and use it for Orc.
I see @rafael blasted it away. What's the reason ?
The C API has stricter backward compatibility constraints than the regular C++ API
So does this mean that C API guarantees binary compatibility between old and new versions? If so then this patch does have a problem.
Yes, except for some parts such as the Orc binding, it does. It is still allowed to deprecate functions and remove them (you'd get a link error from a foreign language, so that's fine).