This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
[ARM][GDB] backtrace does not go beyond libc functions
- From: Sundar Dev <sundarjdevml at gmail dot com>
- To: gdb at sourceware dot org
- Date: Fri, 26 Jun 2015 18:35:23 -0700
- Subject: [ARM][GDB] backtrace does not go beyond libc functions
- Authentication-results: sourceware.org; auth=none
Hi List Members:
First things first- I am using gdbserver 7.6.2 for remote debugging.
The other main components are- GNU libc-2.19 that comes packaged in
Yocto Poky 'Daisy' release for one of my projects. This is
cross-compiled for ARMv7 and we use arm-poky-linux-gnueabi-gcc (GCC)
4.8.2 toolchain.
I use the *non-debug* version of glibc (with no .debug sections in
elf), but built with ARM unwind tables and ARM frame pointer support.
With this setup, when a user space thread is executing a blocking libc
function like poll(), read(), etc., and I attach a remote gdbserver to
the process and try to get backtrace, all I see is the following 4
backtrace frames as shown below-
(gdb) bt
#0 0x758b9190 in poll () from /lib/libc.so.6
#1 0x758b9184 in poll () from /lib/libc.so.6
#2 0x013df120 in ?? ()
#3 0x013df120 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
And address 0x013df120 is in the heap region in proc/<pid>/maps (shown
below) of my process-
root@xyz# cat /proc/621/maps
...<snip>...
01389000-0154e000 rw-p 00000000 00:00 0 [heap]
...<snip>...
I've looked at gdb source code and I know that the version of gdb that I'm using
(7.6.2) has support to backtrace using ARM unwind tables and frame
pointers (see [1] and [2]). But, even then, all I get from GDB
backtrace is the above shown output. Does anybody here have any
comments and/or suggestions?
Thanks,
Sundar Dev
[1] https://sourceware.org/ml/gdb-cvs/2011-02/msg00011.html
[2] https://sourceware.org/ml/gdb-cvs/2011-02/msg00012.html