libc with ARM unwind tables and frame pointers

Sundar Dev sundarjdevml@gmail.com
Fri Jun 26 18:26:00 GMT 2015


Hi List Members:

First things first- we are using GNU libc-2.19 that comes packaged in
Yocto Poky 'Daisy' release for one of our projects. This is
cross-compiled for ARMv7 and we use arm-poky-linux-gnueabi-gcc (GCC)
4.8.2 toolchain.

We use the *non-debug* version of libc in our project for obvious size
and performance reasons. With the non-debug version, when a user space
thread is executing a libc function like poll(), read(), etc., and we
attach a remote gdbserver to the process and try to get backtrace, all
we see is the following 4 backtrace frames-

(gdb) bt
#0  0x759abc00 in poll () from /lib/libc.so.6
#1  0x759abbf4 in poll () from /lib/libc.so.6
#2  0x00182c70 in ?? ()
#3  0x00182c70 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This, I can understand, is because the non-debug version is stripped
of all debug symbols and hence GDB cannot backtrace. But here is the
interesting part- we compiled libc (and all of yocto Poky toolchain
components) with ARM unwind table and ARM frame pointers for another
reason[1]. And, I know that the version of gdb that we're using
(7.6.2) has support to backtrace using ARM unwind tables and frame
pointers (see [2] and [3]). But, even then, all we get from GDB
backtrace is the above shown output. Does anybody have any comments on
why enabling ARM unwind tables and ARM frame pointers in libc still
does not give us backtrace? And is there any other way we can get
backtrace to go past libc functions without including debug sections
in the libc elf?

Thanks,
Sundar Dev

[1] In the release version of our code, we don't want to have our
applications and libraries built with debug symbols (for reasons of
code bloat, performance, etc). But we would still like to get a stack
trace in the event of a crash by using the glibc backtrace() and
backtrace_symbols_fd() APIs. The libgcc implementation of these APIs
works with ARM unwind tables and frame pointers. And hence we build
our application and libraries with -fasynchronous-unwind-tables,
-fno-omit-frame-pointer and -mapcs-frame flags and it works.
[2] https://sourceware.org/ml/gdb-cvs/2011-02/msg00011.html
[3] https://sourceware.org/ml/gdb-cvs/2011-02/msg00012.html



More information about the Libc-help mailing list