Re: libc with ARM unwind tables and frame pointers

[Sundar Dev <sundarjdevml at gmail dot com>]

On Fri, Jun 26, 2015 at 12:57 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> 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]
And also the backtrace APIs don't give us a full backtrace either when
the thread is blocked in a libc function like __poll(). So, I killed
my process with SIGSEGV and I have a signal handler that handles
SIGSEGV and calls backtrace() and backtrace_symbols_fd() to dump out
the stack trace. All I get is the following 3 frames from
backtrace_symbols_fd()-
/sbin/myapp[0x20b68]
/lib/libc.so.6(__default_rt_sa_restorer_v2+0x0)[0x7581bca0]
/lib/libc.so.6(__poll+0x44)[0x758b3194]

The first frame is my signal handler. The second frame is the libc
function that the kernel calls on an exception. And the third frame
was where my thread was stuck when I sent the SIGSEGV. And nothing
beyond that!

So, I think this is something to do with the way glibc is built and it
is not working well with backtrace(). Even adding
-fasynchronous-unwind-tables, -fno-omit-frame-pointer and -mapcs-frame
compiler flags to glibc build is not giving us a backtrace beyond a
libc function. Any comments on this observation?

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