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


>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

 >> 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.

 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


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