LLVM ERROR: Program used external function '___morestack_addr' which could not be resolved! about rusti HOT 24 CLOSED

This seems very odd. I'll need more information about your setup.
What version of rustc are you using? (rustc --version)
What operating system are you using?

from rusti.

rustc 1.0.0-nightly (3ef8ff1f8 2015-02-12 00:38:24 +0000)
OS X Yosemite Version 10.10.2

from rusti.

Have you been able to get rusti to compile before or is this your first attempt?
I don't have access to an OS X system, so I'm afraid I won't be able to help you. I haven't seen this error on Linux at all.

from rusti.

I successfully compiled and used earlier versions of Rusti. I suppose I'll just have to hope that this strange error will go away by itself in later versions. If you wish, I can close the issue.

from rusti.

The error is still occurring in the latest version, so I'm reopening this.

from rusti.

On version rustc 1.0.0-nightly (199bdcfef 2015-03-26) (built 2015-03-26) this is still happening.

from rusti.

On version rustc 1.0.0-nightly (199bdcfef 2015-03-26) (built 2015-03-26) this is still happening.

This bug still live on nightly

rustc -vV
rustc 1.0.0-nightly (abf0548b5 2015-04-15) (built 2015-04-15)
binary: rustc
commit-hash: abf0548b5caaa389a5b29813132d2cf4c8b0f1ed
commit-date: 2015-04-15
build-date: 2015-04-15
host: x86_64-apple-darwin
release: 1.0.0-nightly

seems lowks has asked this problem before

from rusti.

Inserting #[export_name = "___morestack_addr"] right before the definition of morestack_addr in exec.rs fixes this issue for me.

rustc 1.2.0-nightly (0cc99f9cc 2015-05-17) (built 2015-05-17)
binary: rustc
commit-hash: 0cc99f9cc9b59518f618a2c3f5011000e60f922e
commit-date: 2015-05-17
build-date: 2015-05-17
host: x86_64-apple-darwin
release: 1.2.0-nightly

from rusti.

@durka: That is very strange. I never understood why this error was happening in the first place. It seems to me that morestack_addr is only used internally within rusti and I can't figure how it even winds up being resolved by LLVM. Can you shed any light on this?

from rusti.

Yeah, it doesn't make any sense to me either since by the time LLVMRustCreateJITMemoryManager is called, morestack_addr has already been called and returned.

from rusti.

Do we know where in rusti's code the LLVM ERROR occurs? It's certainly not at the morestack_addr call site.

from rusti.

There are only a few calls to the LLVM API from rusti. I would guess it's when the ExecutionEngine is built (with an empty LLVM Module created by the rustc API). Running rusti with env var RUST_LOG=rusti=debug should give an indication of when it happens.

from rusti.

seas800:rusti alex$ RUST_LOG=rusti=debug ./target/debug/rusti
DEBUG:rusti::exec: using sysroot: "/usr/local/Cellar/rust/nightly"
DEBUG:rusti::exec: loading crate /usr/local/Cellar/rust/nightly/lib/rustlib/x86_64-apple-darwin/lib/libstd-11582ce5.dylib
rusti=> 1+1
DEBUG:rusti::repl: read program: Input { attributes: [], view_items: [], items: [], statements: ["1+1"], last_expr: true }
DEBUG:rusti::exec: compiling module
DEBUG:rusti::exec: loading crate /usr/local/Cellar/rust/nightly/lib/rustlib/x86_64-apple-darwin/lib/libstd-11582ce5.dylib
LLVM ERROR: Program used external function '___morestack_addr' which could not be resolved!

from rusti.

But libstd-11582ce5.dylib references only ___morestack not ___morestack_addr.

from rusti.

@murarth I assume you've seen this https://users.rust-lang.org/t/why-is-my-rust-broken-26-02-2015-build/492

from rusti.

Okay, I was wrong. It looks like the initial construction goes fine. (The first "loading crate" message isn't immediately followed by an error.) There's not another log message there to make it clear, but it seems that LLVMExecutionEngineAddModule in add_module is causing the error, which must be when the first actual code is linked in the ExecutionEngine.

That link is interesting. It would appear that __morestack_addr is something provided by LLVM and the fact that rusti has a function morestack_addr is simply a coincidence. The LLVM JIT code should be making its own definition of __morestack_addr available to the symbol resolver.

from rusti.

Yeah... but it isn't? I tried changing morestack_addr to find_morestack_addr in case it was a name shadowing thing, but that didn't fix it.

from rusti.

It seems like it could be a Rust bug, in that morestack_addr should be in libmorestack.a (i.e. morestack.S), but that is way more magic than I can decipher!

from rusti.

I don't think adding the symbol to libmorestack.a would solve this issue. The symbol for morestack needs to be fed to the ExecutionEngine. I think the same may need to be done for morestack_addr. Unless LLVM's internal code is meant to be creating that symbol independently. As this error doesn't occur on Linux (in my experience), I think LLVM is meant to be handling it.

I'm not very knowledgeable about LLVM. I'm trying to get some insight into this on #rust-internals.

from rusti.

Inserting #[export_name = "___morestack_addr"] also works for me.
However, this seems to only work for "cargo run". For some reason "cargo run --release" still experiences the problem.

from rusti.

I'm working on a fix that I'll push to the Rust repo. This bug isn't the result of any rusti code, but rather the code in Rust's LLVM wrapper that builds the ExecutionEngine.

from rusti.

@Sarjo2222, @durka: Can you confirm that this issue is resolved in the latest nightly (2228ce10c 2015-06-09)?

from rusti.

@Sarjo2222, @durka: Can you confirm that this issue is resolved in the latest nightly (2228ce10c 2015-06-09)?

Verified on a Mac

# uname -a
Darwin xxx 14.3.0 Darwin Kernel Version 14.3.0:Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
# cargo run --release
   Compiling regex v0.1.30
   Compiling libc v0.1.8
   Compiling rand v0.3.8
   Compiling log v0.3.1
   Compiling getopts v0.2.11
   Compiling tempfile v0.3.0
   Compiling env_logger v0.3.1
   Compiling rusti v0.0.1 (file:///Users/xxx/rust/rusti)
     Running `target/release/rusti`
rusti=> 1+1
2
# cargo test --release
   Compiling rusti v0.0.1 (file:///Users/xxx/rust/rusti)
     Running target/release/exec-7afabf774ebc3dee
running 5 tests
test test_exec ... ignored
test test_static ... ignored
test test_static_mut ... ignored
test test_thread ... ignored
test test_thread_local ... ignored
test result: ok. 0 passed; 0 failed; 5 ignored; 0 measured
     Running target/release/repl-2084aa6840fec652
running 5 tests
test test_rc ... ok
test test_file ... ok
test test_print ... ok
test test_type ... ok
test test_eval ... ok
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured
   Doc-tests rusti
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
# rustc -vV
rustc 1.2.0-nightly (2228ce10c 2015-06-09)
binary: rustc
commit-hash: 2228ce10c6d83c17b6346396aa7c7ef9082f1c04
commit-date: 2015-06-09
host: x86_64-apple-darwin
release: 1.2.0-nightly

from rusti.

👍

from rusti.