Can't seem to load compiler plugin



I’m trying to write a compiler plugin (a MultiDecorator). It actually wen’t pretty well in the begining, I’ve managed to add some hello-world-kind-of AST. The problem is I need to link to part of the code (a ‘backend’ if you will) that is written in C++ with C interface provided. I’ve decided to split the whole thing into a backend shared library and the plugin dylib that links to the backend library and uses its C interface. The plugin compiles allright, but when I try to use it in a test project, rustc will crash trying to load it up (SIGILL somewhere in PluginLoader).

The backend shared object is symlinked to /usr/lib so I reckon it should be accessible, shouldn’t it? ldd seems to find it.

I’ve also tried comiling the backend statically and linking the plugin into one dylib, but rustc seems to be unable to link the C++ parts together (which doesn’t really surprise me).


Here’s a backtrace if anyone’s interested…

(gdb) bt
#0  0x00007ffff7148528 in raise () from /usr/lib/
#1  0x00007ffff714993a in abort () from /usr/lib/
#2  0x00007ffff71413a7 in __assert_fail_base () from /usr/lib/
#3  0x00007ffff7141452 in __assert_fail () from /usr/lib/
#4  0x00007ffff2b99db2 in void llvm::cl::parser<llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>::addLiteralOption<llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>(char const*, llvm::ScheduleDAGSDNodes* (* const&)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level), char const*) [clone .part.641] ()
   from /usr/local/lib/
#5  0x00007ffff2ba35a9 in llvm::RegisterPassParser<llvm::RegisterScheduler>::NotifyAdd(char const*, void* (*)(), char const*) () from /usr/local/lib/
#6  0x00007fffe54c2345 in _GLOBAL__sub_I_SelectionDAGISel.cpp () from /usr/lib/
#7  0x00007ffff7dea0ea in call_init.part () from /lib64/
#8  0x00007ffff7dea1fb in _dl_init () from /lib64/
#9  0x00007ffff7dee627 in dl_open_worker () from /lib64/
#10 0x00007ffff7de9f94 in _dl_catch_error () from /lib64/
#11 0x00007ffff7dede01 in _dl_open () from /lib64/
#12 0x00007ffff11a3fc9 in ?? () from /usr/lib/
#13 0x00007ffff7de9f94 in _dl_catch_error () from /lib64/
#14 0x00007ffff11a45e1 in ?? () from /usr/lib/
#15 0x00007ffff11a4061 in dlopen () from /usr/lib/
#16 0x00007ffff756d2ec in dynamic_lib::DynamicLibrary::open::he0c1304b546ffce32Vd () from /usr/local/lib/
#17 0x00007ffff57bceeb in plugin::load::PluginLoader$LT$$u27$a$GT$::load_plugin::h265a03a886fb7e43wDs () from /usr/local/lib/
#18 0x00007ffff57bc7b7 in plugin::load::load_plugins::he89c54f2a18bc6debAs () from /usr/local/lib/
#19 0x00007ffff7ae75e3 in driver::phase_2_configure_and_expand::h78b6b5f9e6647529Ysa () from /usr/local/lib/
#20 0x00007ffff7ad8dbb in driver::compile_input::h8626aa78c5d4da0eQba () from /usr/local/lib/
#21 0x00007ffff7b90b42 in run_compiler::h96c05ebaa828b862o6b () from /usr/local/lib/
#22 0x00007ffff7b8e393 in boxed::F.FnBox$LT$A$GT$::call_box::h14824596170961889198 () from /usr/local/lib/
#23 0x00007ffff7b8db6a in rt::unwind::try::try_fn::h5275104876552890265 () from /usr/local/lib/
#24 0x00007ffff7624449 in rust_try_inner () from /usr/local/lib/
#25 0x00007ffff7624436 in rust_try () from /usr/local/lib/
#26 0x00007ffff75971f8 in rt::unwind::try::inner_try::h38b71de3b475180cInw () from /usr/local/lib/
#27 0x00007ffff7b8dd9b in boxed::F.FnBox$LT$A$GT$::call_box::h1459658178567901908 () from /usr/local/lib/
#28 0x00007ffff75aa422 in sys::thread::Thread::new::thread_start::h21edeab345ab83b4Yxv () from /usr/local/lib/
#29 0x00007ffff15c4354 in start_thread () from /usr/lib/
#30 0x00007ffff71fcbfd in clone () from /usr/lib/

Edit: Never mind, this was due to LLVM linkage problems. Sorry for the monologue :slight_smile:


FWIW I’d gotten a similar crash with llvm::ScheduleDAGSDNodes in the signature in the past around plugin loading.

(Except that time I was working on the plugin loading system, so I thought it was my fault – it wasn’t, llvm was randomly broken)


Hmm… I my case I got different kinds of crashes depending on the rustc release… I’m not sure but I think it was my fault in this case - that it’s not possible to have more LLVM instances in one process (think of all the llvm global init functions)…