From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9001 invoked by alias); 7 Aug 2008 09:30:42 -0000 Received: (qmail 8993 invoked by uid 22791); 7 Aug 2008 09:30:42 -0000 X-Spam-Check-By: sourceware.org Received: from ocean.emcraft.com (HELO ocean.emcraft.com) (213.221.7.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Aug 2008 09:29:46 +0000 Received: from [172.17.0.10] (helo=[172.17.0.10]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1KR1oM-0006OJ-IU; Thu, 07 Aug 2008 13:29:42 +0400 Message-ID: <489AC07E.2020603@emcraft.com> Date: Thu, 07 Aug 2008 09:30:00 -0000 From: Sergei Poselenov User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Sergei Poselenov , gdb@sources.redhat.com Subject: Re: Problem reading corefiles on ARM References: <4899C0FE.4010008@emcraft.com> <20080806152736.GA31492@caradoc.them.org> In-Reply-To: <20080806152736.GA31492@caradoc.them.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Report: Spam detection software, running on the system "ocean.emcraft.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. > [...] Content analysis details: (-4.2 points, 2.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00123.txt.bz2 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 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