From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32750-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10480 invoked by alias); 6 Aug 2008 15:45:38 -0000
Received: (qmail 10463 invoked by uid 22791); 6 Aug 2008 15:45:37 -0000
X-Spam-Check-By: sourceware.org
Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Aug 2008 15:45:01 +0000
Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) 	by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m76FgnMm020494; 	Wed, 6 Aug 2008 17:42:49 +0200 (CEST)
Received: (from kettenis@localhost) 	by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m76FgmUv017348; 	Wed, 6 Aug 2008 17:42:48 +0200 (CEST)
Date: Wed, 06 Aug 2008 15:45:00 -0000
Message-Id: <200808061542.m76FgmUv017348@brahms.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org, gcc@sources.redhat.com
CC: sposelenov@emcraft.com, gdb@sources.redhat.com
In-reply-to: <20080806152736.GA31492@caradoc.them.org> (message from Daniel 	Jacobowitz on Wed, 6 Aug 2008 11:27:36 -0400)
Subject: Re: Problem reading corefiles on ARM
References: <4899C0FE.4010008@emcraft.com> <20080806152736.GA31492@caradoc.them.org>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-08/txt/msg00103.txt.bz2

> Date: Wed, 6 Aug 2008 11:27:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.

GCC should really not do this.  People are almost guaranteed to want
to be able to see a backtrace from abort(3).

I suppose it optimizes away the instructions to save the return
address, because abort() is marked with __attribute__(noreturn).  But
that means there is very little point in actually doing that
optimization since __attribute__(noreturn) implies that the function
will only be called once!  I suppose there are some space savings but
are they really significant?