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

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

[Sundar Dev]

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

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

[Yao Qi]

Sundar Dev <sundarjdevml@gmail.com> writes:

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

The address 0x013df120 in frame #2 is got from frame #1 by unwinding.
The unwinding can be wrong, so address 0x013df120 can be wrong too.

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

I don't have much suggestions to give, unless I can reproduce it.  GDB
tries different unwinders to unwind a certain frame, which means
exception table unwinder may be used or may not be used.  You can debug
GDB to see which unwinder is used, and identify why the bad pc
(0x013df120) is got from the unwinding.

-- 
Yao (齐尧)