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]

Re: Problem reading corefiles on ARM


Hello Daniel, all,


Daniel Jacobowitz wrote:
On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
(gdb) bt
#0  0x4004ec0c in raise () from /lib/libc.so.6
#1  0x40050234 in abort () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC

Your implementation of abort does not save a return address, so GDB can't display it. I believe tehis is a known limitation of the ARM GCC port.


Thanks, I've got the point.
Indeed, changing abort() to invalid memory reference makes backtrace work.


How about threaded applications?

-bash-3.2# gdb linux-dp core.969
GNU gdb Red Hat Linux (6.7-1rh)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.3...done.
Loaded symbols for /lib/ld-linux.so.3
Core was generated by `./linux-dp'.
Program terminated with signal 11, Segmentation fault.
#0 0x400ce8e4 in nanosleep () from /lib/libc.so.6
(gdb) bt
#0 0x400ce8e4 in nanosleep () from /lib/libc.so.6
#1 0x400ce8d4 in nanosleep () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info thr
6 process 970 0x00000000 in ?? ()
5 process 971 0x00000000 in ?? ()
4 process 972 0x00000000 in ?? ()
3 process 973 0x00000000 in ?? ()
2 process 974 0x00000000 in ?? ()
* 1 process 969 0x400ce8e4 in nanosleep () from /lib/libc.so.6
(gdb) thr 3
[Switching to thread 3 (process 973)]#0 0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x00000000 in ?? ()
(gdb)


This time, the core was generated by "kill -SIGSEGV".

Could it be a kernel bug?

Regards,
Sergei


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