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

Can't resolve libc symbol - which is found by C addr2line #250

Closed
Matthias247 opened this issue Jun 14, 2022 · 4 comments · Fixed by gimli-rs/object#443
Closed

Can't resolve libc symbol - which is found by C addr2line #250

Matthias247 opened this issue Jun 14, 2022 · 4 comments · Fixed by gimli-rs/object#443

Comments

@Matthias247
Copy link

I'm trying to reverse lookup a symbols based on addresses using this library. While it works for a Rust executable, I had less luck with a C .so.

One example I wanted to lookup was the __sendmmsg function.

objdump shows the address at 0x123d90:

objdump -t -T /usr/lib/x86_64-linux-gnu/libc-2.31.so | grep __sendmmsg
0000000000123d90 g    DF .text  00000000000000a5  GLIBC_PRIVATE __sendmmsg

Ubuntu addr2line finds the symbol:

addr2line -e  /usr/lib/x86_64-linux-gnu/libc-2.31.so -f -i -a 123d90
0x0000000000123d90
__sendmmsg
??:?

But gimli-rs/addr2line can't find it:

cargo run --example addr2line -- --exe  /usr/li
b/x86_64-linux-gnu/libc-2.31.so -f -i -a 123d90
0x0000000000123d90
??
??:0

In case it matters for reproduction: I'm running this on WSL2 with a Ubuntu 20.4 distribution

@philipc
Copy link
Contributor

philipc commented Jun 14, 2022

This is a bug in the object crate. symbol_table always returns Some, which means it never falls back to dynamic_symbol_table if the debugging symbol table is empty.

However, even if that is fixed, addr2line won't provide very good results without DWARF debugging information (whether this crate or the Ubuntu version of addr2line). I suggest that if you want to look up addresses in libc then you install the debug package for it and use that.

@Matthias247
Copy link
Author

Thanks for the quick response!

You mean with the fix it still wouldn't return a result for this particular example - or that it might still have issues with other executables/libraries that lack debuginfo?

What I'm currently up to is trying to translate some stacktraces that I get via ebpf based profiling, in a similar way that bpftrace does it via the ustack macro. Since that is supposed to provide as much information as possible about arbitrary software on a host, installing additional debug packages might not be an option. It's simply a "more information is better" approach, and if something is missing its not the end of the world. I just thought since the C tool can resolve the symbol it might also be doable using gimli-rs.

@philipc
Copy link
Contributor

philipc commented Jun 14, 2022

With the fix it will return the result for this example, but there are other addresses that it won't return any result for, and neither will the system addr2line. Also, as seen by the ??:? that you get, it can't return any line number information. If you just want whatever existing information there is, then that's fine, I was just pointing out that you could get more information by installing the DWARF debug package, and that would work without needing any fix.

@philipc
Copy link
Contributor

philipc commented Jun 14, 2022

Oh, and note that the addr2line library itself doesn't use symbol tables at all so it will never return the result. It's only in the example that they are used.

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