<div dir="ltr">On Thu, May 16, 2013 at 5:36 PM, Filip Pizlo <span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="im"><div>On May 16, 2013, at 3:20 PM, Sean Silva <<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>> wrote:</div>
<br><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr">On Thu, May 16, 2013 at 3:10 PM, Filip Pizlo<span> </span><span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>></span><span> </span>wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto">
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. :-)</div>
</blockquote><div><br></div><div>Unfortunately, it can break in the presence of shared libraries:</div><div><br></div><div><div>shared library A, compiled against LLVM API v1:</div><div>void runMCJIT(void) {</div><div>  LLVMMCJITMemoryManagerFunctions MCJMM; // v1</div>
<div>  setupMCJMM(&MCJMM);</div><div>}</div><div><br></div><div>shared library B, recently upgraded, compiled against LLVM API v2:</div><div>void setupMCJMM(LLVMMCJITMemoryManagerFunctions *p) {</div><div>  p->FunctionAddedInV2 = ...; // BOOM, overwriting caller's stack</div>
<div>}</div><div><br></div><div>Avoiding this kind of issue would force the API clients to replicate the brittle sizeof checking in their own code.</div></div></div></div></div></div></blockquote><div><br></div></div><div>
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?</div></div></div></blockquote><div><br></div><div style>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>  I'm not sure if this concern should drive the design here,</div>
</div></div></blockquote><div style><br></div><div style>Indeed. I didn't mean to suggest that. Sorry for the confusion.</div><div style><br></div><div style>-- Sean Silva</div></div><br></div></div>