Re: Problem reading corefiles on ARM

[Sergei Poselenov <sposelenov@emcraft.com>]

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