LLVM Interepreter (lli) and shared object loading

Question

I'm trying to use lli to interpret/JIT-compile a bitcode file a.bc that uses functions defined in a shared object afl-llvm-rt.so. When I try to use lli like this

lli -dlopen ./afl-llvm-rt.so a.bc

I get:

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.  Program arguments: lli -load ./afl-llvm-rt.o a.bc 
#0 0x00007fa2a620f833 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa99833)
#1 0x00007fa2a620dbe0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa97be0)
#2 0x00007fa2a620fe65 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa99e65)
#3 0x00007fa2a57683c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
zsh: segmentation fault (core dumped)  lli -load ./afl-llvm-rt.o a.bc

Further investigation with gdb reveals that the function addresses are not set:

> gdb lli
(gdb) r -load ./afl-llvm-rt.o a.bc
Starting program: /usr/bin/lli -load ./afl-llvm-rt.o a.bc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7fca021 in sancov.module_ctor_trace_pc_guard ()
#2  0x00007ffff4f46118 in llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) () from /lib/x86_64-linux-gnu/libLLVM-12.so.1
#3  0x00007ffff4ef9a57 in llvm::ExecutionEngine::runStaticConstructorsDestructors(llvm::Module&, bool) () from /lib/x86_64-linux-gnu/libLLVM-12.so.1
#4  0x00007ffff4f4587f in llvm::MCJIT::runStaticConstructorsDestructors(bool)
    () from /lib/x86_64-linux-gnu/libLLVM-12.so.1
#5  0x000000000041391b in main ()

However, if I compile the file as usual, with clang a.bc ./afl-llvm-rt.so, the output executable works just fine.

How do I make lli dynamically link a.bc with afl-llvm-rt.so?

EDIT: I compiled afl-llvm-rt.so to be a LLVM IR file instead, then I used llvm-link a.bc afl-llvm-rt.bc -o result.bc to link them together. After that, I tried lli result.bc, which gives the following:

ocelaiwo@E490:~/Misc/ff> lli result.bc
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lli result.bc 
#0 0x00007efc8d3d9833 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa99833)
#1 0x00007efc8d3d7be0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa97be0)
#2 0x00007efc8d3d9e65 (/lib/x86_64-linux-gnu/libLLVM-12.so.1+0xa99e65)
#3 0x00007efc8c9323c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
zsh: segmentation fault (core dumped)  lli result.bc

But if I clang result.bc -o result, the result executable executes just fine.

score 0 · Answer 1 · 2021-05-05T08:39:52.770

Try the --load option to lli, as answered here. Example code that would use the glib library:

lli --load=/usr/lib/x86_64-linux-gnu/libglib-2.0.so my-bicode-file.bc

I've also found that the option -force-interpreter serves as a useful debugging tip, e.g it can show the missing symbol:

LLVM ERROR: Could not resolve external global address: some_external_symbol

You can then investigate where that symbol (e.g function) might be on your system.

LLVM Interepreter (lli) and shared object loading

1 Answers1