Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: unhandled llvm intrinsic: llvm.abs.i32 #74

Closed
64kramsystem opened this issue Aug 19, 2022 · 2 comments · Fixed by #78
Closed

BUG: unhandled llvm intrinsic: llvm.abs.i32 #74

64kramsystem opened this issue Aug 19, 2022 · 2 comments · Fixed by #78

Comments

@64kramsystem
Copy link

64kramsystem commented Aug 19, 2022

Hello!

I get the bug BUG: unhandled llvm intrinsic: llvm.abs.i32, when trying to execute the program on my project.

Test case:

git clone [email protected]:64kramsystem/catacomb_ii-64k.git
cd catacomb_ii-64k
cat >> Cargo.toml << TOML                                                 
[profile.release]
lto = true # "fat" yields the same problem
TOML
cargo +nightly call-stack --bin catacomb --target x86_64-unknown-linux-gnu

Output:

[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `_init`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `_init`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `_start`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `_start`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `deregister_tm_clones`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `deregister_tm_clones`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `register_tm_clones`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `register_tm_clones`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `__do_global_dtors_aux`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `__do_global_dtors_aux`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `frame_dummy`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `frame_dummy`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `__rust_probestack`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `__rust_probestack`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `__libc_csu_init`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `__libc_csu_init`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `__libc_csu_fini`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `__libc_csu_fini`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `atexit`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `__fstat`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `stat64`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `fstat64`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no stack usage information for `_fini`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] no type information for `_fini`
[2022-08-19T10:04:51Z WARN  cargo_call_stack] assuming that `llvm.umul.with.overflow.i64` directly lowers to machine code
thread 'main' panicked at 'BUG: unhandled llvm intrinsic: llvm.abs.i32', /home/saverio/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-call-stack-0.1.11/src/main.rs:731:21
stack backtrace:
   0: rust_begin_unwind
             at /rustc/65f3f8b220f020e562c5dd848ff7319257a7ba45/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/65f3f8b220f020e562c5dd848ff7319257a7ba45/library/core/src/panicking.rs:107:14
   2: cargo_call_stack::run
   3: cargo_call_stack::main
@64kramsystem
Copy link
Author

Thanks! 🤩

japaric added a commit that referenced this issue Nov 16, 2022
@japaric
Copy link
Owner

japaric commented Nov 16, 2022

release v0.1.13 includes a fix for this but you'll likely hit #61 afterwards as there's no graceful support for dynamically linked binaries (yet)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants