From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29478 invoked by alias); 6 Aug 2008 16:02:32 -0000 Received: (qmail 29458 invoked by uid 22791); 6 Aug 2008 16:02:31 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkps320.us.dell.com (HELO aussmtpmrkps320.us.dell.com) (143.166.224.254) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Aug 2008 16:01:51 +0000 X-IronPort-AV: E=Sophos;i="4.31,315,1215406800"; d="scan'208";a="368883766" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 06 Aug 2008 11:01:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18585.51522.726379.18666@gargle.gargle.HOWL> Date: Wed, 06 Aug 2008 16:02:00 -0000 From: Paul Koning To: mark.kettenis@xs4all.nl Cc: drow@false.org, gcc@sources.redhat.com, sposelenov@emcraft.com, gdb@sources.redhat.com Subject: Re: Problem reading corefiles on ARM References: <4899C0FE.4010008@emcraft.com> <20080806152736.GA31492@caradoc.them.org> <200808061542.m76FgmUv017348@brahms.sibelius.xs4all.nl> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-IsSubscribed: yes 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/msg00105.txt.bz2 >>>>> "Mark" == Mark Kettenis writes: >> Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz >> >> >> 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. Mark> GCC should really not do this. People are almost guaranteed to Mark> want to be able to see a backtrace from abort(3). Absolutely. Mark> I suppose it optimizes away the instructions to save the return Mark> address, because abort() is marked with Mark> __attribute__(noreturn). But that means there is very little Mark> point in actually doing that optimization since Mark> __attribute__(noreturn) implies that the function will only be Mark> called once! I suppose there are some space savings but are Mark> they really significant? I think the space savings in "noreturn" come from not having to save caller-saved registers in the calling function. That savings can add up if the noreturn function is called from many places. Clearly the return address needs to be saved in the case of functions like "abort". Come to think of it, probably all the usual registers should be saved, so you can examine variables in the function that called abort and not get nonsense. It sounds to me like the "noreturn" attribute should be removed from "abort". paul