llvm dev - Oct 2019 - Problem resolving symbols in dylibs in LLVM 8 vs LLVM 6

Hello,

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.

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.



Here is the LLVM IR which produced the assembly above:


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.

Symbols within the module the execution engine was constructed with are resolved
correctly; only symbols within loaded dynamic libraries fail to resolve.

Using LLVMSearchForAddressOfSymbol does correctly resolve the symbols from the
dynamic library — it’s only when JITed that resolution fails.

My questions are:

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.
Were there any changes to the way LLVM's JIT resolves symbols between LLVM 6
and LLVM 8?
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).


I’d appreciate any help or suggestions. I’m unsure how to proceed debugging or
fixing this.


Thanks,
Connor
 



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191011/e1895468/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.40.09 PM.png
Type: image/png
Size: 65575 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191011/e1895468/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.55.42 PM.png
Type: image/png
Size: 14585 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191011/e1895468/attachment-0003.png>

+Lang in case he's got some thoughts here

On Sat, Oct 12, 2019 at 5:29 PM Connor Gray via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> 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.
>
> 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.
>
>
> Here is the LLVM IR which produced the assembly above:
>
> 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.
>
> Symbols within the module the execution engine was constructed with are
> resolved correctly; only symbols within loaded dynamic libraries fail to
> resolve.
>
> Using LLVMSearchForAddressOfSymbol does *correctly* resolve the symbols
> from the dynamic library — it’s only when JITed that resolution fails.
>
> My questions are:
>
>
>    1. 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.
>    2. Were there any changes to the way LLVM's JIT resolves symbols
>    between LLVM 6 and LLVM 8?
>       - 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).
>
>
>
> I’d appreciate any help or suggestions. I’m unsure how to proceed
> debugging or fixing this.
>
>
> Thanks,
> Connor
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191013/7e3fed34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.40.09 PM.png
Type: image/png
Size: 65575 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191013/7e3fed34/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.55.42 PM.png
Type: image/png
Size: 14585 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191013/7e3fed34/attachment-0003.png>

Hi Connor,

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 Data Layout
<https://llvm.org/docs/LangRef.html#data-layout>).

-- Lang.

On Sun, Oct 13, 2019 at 11:29 AM Connor Gray via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> 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.
>
> 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.
>
>
> Here is the LLVM IR which produced the assembly above:
>
> 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.
>
> Symbols within the module the execution engine was constructed with are
> resolved correctly; only symbols within loaded dynamic libraries fail to
> resolve.
>
> Using LLVMSearchForAddressOfSymbol does *correctly* resolve the symbols
> from the dynamic library — it’s only when JITed that resolution fails.
>
> My questions are:
>
>
>    1. 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.
>    2. Were there any changes to the way LLVM's JIT resolves symbols
>    between LLVM 6 and LLVM 8?
>       - 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).
>
>
>
> I’d appreciate any help or suggestions. I’m unsure how to proceed
> debugging or fixing this.
>
>
> Thanks,
> Connor
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191216/bc13e5e1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.40.09 PM.png
Type: image/png
Size: 65575 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191216/bc13e5e1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-10-11 at 10.55.42 PM.png
Type: image/png
Size: 14585 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191216/bc13e5e1/attachment-0003.png>