[PATCH] Expose custom MC-JIT memory allocation through the C API

[Sean Silva]

On Thu, May 16, 2013 at 5:36 PM, Filip Pizlo <fpizlo at apple.com> wrote:

>
> On May 16, 2013, at 3:20 PM, Sean Silva <silvas at purdue.edu> wrote:
>
> On Thu, May 16, 2013 at 3:10 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
>> AFAIK, this is no less robust than an opaque struct. Both handle added
>> functions gracefully, and neither can handle removed functions gracefully
>> unless we do something crazy. The un-opaque struct just makes writing the
>> code a bit easier, both for LLVM and for the client. But that's just my
>> opinion. :-)
>>
>
> Unfortunately, it can break in the presence of shared libraries:
>
> shared library A, compiled against LLVM API v1:
> void runMCJIT(void) {
>   LLVMMCJITMemoryManagerFunctions MCJMM; // v1
>   setupMCJMM(&MCJMM);
> }
>
> shared library B, recently upgraded, compiled against LLVM API v2:
> void setupMCJMM(LLVMMCJITMemoryManagerFunctions *p) {
>   p->FunctionAddedInV2 = ...; // BOOM, overwriting caller's stack
> }
>
> Avoiding this kind of issue would force the API clients to replicate the
> brittle sizeof checking in their own code.
>
>
> Why would you do this?  I.e., why would you ever want to have
> initialization of the MCJIT memory management functions span multiple
> shared libraries?
>

I didn't mean to suggest that it would likely be an issue in this
particular case; I was just exhibiting an example where it *can* break. The
usage of MCJMM in the example is completely incidental (it happened to be
the first thing that came to mind).


>  I'm not sure if this concern should drive the design here,
>

Indeed. I didn't mean to suggest that. Sorry for the confusion.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130516/e96af6a5/attachment.html>