Skip to content

"unknown" function names on armv7-linux-androideabi, dl_iterate_phdr is not used. #227

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

Closed
artemii235 opened this issue Jul 17, 2019 · 1 comment · Fixed by #228
Closed

Comments

@artemii235
Copy link

Android has "dl_iterate_phdr" since API version 21, but it's explicitly disabled in backtrace-sys build.rs
So when I run the code

use backtrace::Backtrace;
fn main() {
    println!("{:?}", Backtrace::new());
}

using backtrace 0.3.32 I get following output:

stack backtrace:
   0: <unknown> (0xad95e4e8)
   1: <unknown> (0xad95e4c6)
   2: <unknown> (0xad95d7b8)
   3: <unknown> (0xad95d770)
   4: <unknown> (0xad95c718)
   5: <unknown> (0xad95c67e)
   6: <unknown> (0xad96bb22)
   7: <unknown> (0xad96c77a)
   8: <unknown> (0xad96c056)
   9: <unknown> (0xad95c670)
  10: __libc_init (0xea95978a)

This commit fixes the issue and I get proper backtrace, however this won't build for API versions < 21 /target/armv7-linux-androideabi/debug/deps/libbacktrace_sys-88b2f68ba9256347.rlib(elf.o):elf.c:function __rbt_backtrace_initialize: error: undefined reference to 'dl_iterate_phdr'. I've not submitted a PR yet as someone's build might be broken.

I wonder if this is possible to detect the used android API version and set the build.define("HAVE_DL_ITERATE_PHDR", "1"); accordingly.
Or maybe it's fine to mention that >=21 version is only supported since it's used on CI builds?
Please advice.

@artemii235 artemii235 changed the title "unknown" function names in backtrace on armv7-linux-androideabi, dl_iterate_phdr is not used. "unknown" function names on armv7-linux-androideabi, dl_iterate_phdr is not used. Jul 17, 2019
@alexcrichton
Copy link
Member

Thanks for the report! This definitely makes sense and probably explains #151 as a long-lost issue as well.

I think that we could probably fix this for this crate, but we likely can't fix it for libstd for now. That's probably better than nothing though!

My guess as to the best fix is what you're thinking, somehow detect in the build script what the Android API version is and go from there. For the standard library we don't want to embed references to dl_iterate_phdr since that would change the binary compatibility and we're not quite ready to do that, but for the crate on crates.io we can customize to the toolchain we happen to find.

The perfect solution to this would be to update the C code to use dlsym to dynamically determine if dl_iterate_phdr is available (or somehow like that determine dynamically), but updating the C code isn't really feasible at this point. We should fix this in the findshlibs crate at some point, but that's a problem for later!

alexcrichton added a commit that referenced this issue Jul 17, 2019
Dynamically determine at build time whether the Android API version is
high enough such that we can enable the usage of `dl_iterate_phdr`. This
means that builds for old API revisions like libstd won't pull in new
binary deps, but builds on crates.io of this crate with newer toolchains
should have better backtraces by default.

Some tests for actually executing Android tests have now been enabled on
CI as well which were failing previously and after this change are now
working.

Closes #151
Closes #227
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