<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Connor,<div><br></div><div>What platform are you running on? If Darwin, this might be a linker-mangling issue. Are you setting -m:o in your JIT'd module data layouts? (See <a href="https://llvm.org/docs/LangRef.html#data-layout">Data Layout</a>).</div><div><br></div><div>-- Lang. </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 11:29 AM Connor Gray via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hello,<br><div><br></div><div>I recently updated a project which had been using LLVM 6 to LLVM 8, and ran into an issue where symbols which exist in libraries loaded with LLVMLoadLibraryPermanently — which were correctly resolved by the MCJIT in LLVM 6 — are resolved as the constant $0x0 (null) in LLVM 8, causing a crash in what had been working code.</div><div><br></div><div>The image below shows what’s seen in the debugger. Note the call of %rax on the last line, which had $0x0 stored into it two lines previously.</div><div><br></div><div><img id="gmail-m_4646143950806470854E8D60CB5-9B7A-45E3-8DC7-994CBB12D9A6" width="509" height="104" src="cid:16f0bf3ab5c7e2232a61"></div><div><br></div><div>Here is the LLVM IR which produced the assembly above:</div><div><img id="gmail-m_4646143950806470854CA8D121E-E10A-4CE4-92C8-248CFC9BE1D0" width="313" height="53" src="cid:16f0bf3ab5ce834d7b52"></div><div><br></div><div>The project uses the LLVM C API (via the Rust llvm-sys crate) and had no other changes between the working and the new non-working state.</div><div><br></div><div>Symbols within the module the execution engine was constructed with are resolved correctly; only symbols within loaded dynamic libraries fail to resolve.</div><div><br></div><div>Using LLVMSearchForAddressOfSymbol does <i>correctly</i> resolve the symbols from the dynamic library — it’s only when JITed that resolution fails.</div><div><br></div><div>My questions are:</div><div><br></div><div><ol><li>Is there a way to get LLVM JIT to crash when a symbol fails to resolve, rather than fill in a constant null? That it didn’t crash in the first place was surprising to me — it took a whole day to track down that this resolution failure was even the problem.</li><li>Were there any changes to the way LLVM's JIT resolves symbols between LLVM 6 and LLVM 8?</li><ul><li>I checked the documentation for the LLVMCreateJITCompiledForModule and LLVMLoadLibraryPermanently but found nothing to suggest the behavior would have changed (no deprecation warning, no new documentation).</li></ul></ol></div><div><br></div><div><br></div><div>I’d appreciate any help or suggestions. I’m unsure how to proceed debugging or fixing this.</div><div><br></div><div><br></div><div>Thanks,</div><div>Connor</div><div> </div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>