Re: libc with ARM unwind tables and frame pointers

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

Hi

On 26-06-2015 15:26, Sundar Dev wrote:
> 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?

In fact your debug session GDB is indeed getting a stacktrace, what 
it is not being to do is associate the address with meaningful names.
This is due not because missing debug information, but because not all
symbols in the executable are in dynamic symbol table.

Backtrace man pages explains it briefly in 'NOTES' section and you
need to add -rdynamic compiler flags (which is will be translated to
-export-dynamic linker option). In a armhf environment using the
man pages example:

$ ./test 3
backtrace() returned 0 addresses
$ gcc -Wall test.c -O3 -o test -funwind-tables
$ ./test 3
backtrace() returned 3 addresses
./test() [0x8710]
./test() [0x8620]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x99) [0xf76aa632]
$ gcc -Wall test.c -O3 -o test -funwind-tables -rdynamic
$ ./test 3
backtrace() returned 3 addresses
./test(myfunc3+0xb) [0x8968]
./test(main+0x33) [0x8878]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x99) [0xf70c6632]


> 
> 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
>