This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ARM][GDB] backtrace does not go beyond libc functions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]