Page MenuHomePhabricator

MCJIT: Support setting relocation model from C wrappers
AbandonedPublic

Authored by evgeny777 on Jan 27 2017, 8:19 AM.

Details

Summary

Also added unit tests which uses MCJIT to create position independent code.

Diff Detail

Event Timeline

evgeny777 created this revision.Jan 27 2017, 8:19 AM
davide edited edge metadata.Jan 28 2017, 12:32 AM

I think the code is fine, but why do you need to introduce a new API for this (i.e. which problem you're trying to solve?)

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)

davide requested changes to this revision.Jan 28 2017, 12:39 AM
This revision now requires changes to proceed.Jan 28 2017, 12:39 AM

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:
https://reviews.llvm.org/D28571

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.

Also, I and @rafael have ideas on how to change the reloc model to include PIE

I don't know much about differences between PIC and PIE reloc models, but how adding extra enum member affects this patch (besides extra line in CodeGenCWrappers.h)?

deadalnix added inline comments.Jan 28 2017, 6:12 AM
include/llvm-c/ExecutionEngine.h
46

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.

include/llvm/Support/CodeGenCWrappers.h
63

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.

evgeny777 added inline comments.Jan 28 2017, 8:04 AM
include/llvm-c/ExecutionEngine.h
46

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.

include/llvm/Support/CodeGenCWrappers.h
63

Just because there is no such enumeration value. See llvm/Support/CodeGen.h

deadalnix added inline comments.Jan 28 2017, 3:15 PM
include/llvm-c/ExecutionEngine.h
46

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.

include/llvm/Support/CodeGenCWrappers.h
63

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.

deadalnix edited edge metadata.Jan 31 2017, 9:18 AM

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).

evgeny777 abandoned this revision.Feb 6 2017, 11:59 PM