search

japaric / cargo-call-stack

Whole program static stack analysis
Apache License 2.0
560 stars 50 forks source link

thread 'main' panicked at 'BUG: callee `XYZ` is unknown' / (minimally) handle dynamically linked binaries #61

Open japaric opened 2 years ago

japaric commented 2 years ago

dynamically linked binaries contain 'undefined' symbols

$ file hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2

$ nm -CSn hello
                 U abort@GLIBC_2.2.5
                 U bcmp@GLIBC_2.2.5
                 U calloc@GLIBC_2.2.5
(..)

these symbols are provide at runtime by a dynamic linker (e.g. /lib/ld-linux.so.2). Therefore cargo-call-stack, a static analysis tool, cannot provide a complete call graph for these kind of binaries.

Currently cargo-call-stack panics when it sees these kind of binaries. We should more gracefully handle these binaries by adding a dummy node that represents the dynamic libraries provided by the environment (dynamic linker) to the call graph and having all calls into 'undefined' symbols be connected to that dummy node.

It's not possible to provide a max stack usage number for dynamically linked binaries so that should also be reported to the console.

Workaround

If you are hitting the "thread 'main' panicked at 'BUG: callee XYZ is unknown'" error message try using a compilation target that produces a statically linked binary. If you were using x86_64-unknown-linux-gnu then use x86_64-unknown-linux-musl.

ryankurte commented 1 year ago

it seems this also occurs with static binaries when using build-std with compiler_builtins and build-std-features = ["compiler-builtins-mem"] (without which i get panicked at 'compiler_builtins' LLVM IR unavailable')?