On Friday 04 November 2011 10:07:08 Rich Felker wrote: > On Fri, Nov 04, 2011 at 03:08:25AM +0000, Grant Edwards wrote: > > On 2011-11-04, Rich Felker <dal...@aerifal.cx> wrote: > > > On Thu, Nov 03, 2011 at 01:23:30PM +0000, Grant Edwards wrote: > > >> It appears that the abort() function somehow breaks the resulting > > >> corefile so that you can't do a post-mortem backtrace. I suspect that > > >> gcc has figured out that the abort() function never returns, so it > > >> doesn't push a return address onto the stack. > > >> > > >> I've managed to work around the problem by doing something like this > > >> > > >> to cause a segfault instead of calling abort(): > > >> *((volatile char*)0) = 0; > > >> > > >> That produces a usable core file. > > >> > > >> But, it would be nice if abort() could be "fixed" somehow... > > > > > > This probably just entails eliminating the noreturn attribute from the > > > prototype... > > > > That's what I thought at first, but when I looked at the source code I > > couldn't find it... Ah, there it is... I finally found the include > > files by switching to the "future" branch. There are no include files > > under "master" for some reason. Well, there are now, but 10 minutes > > ago it said "no repository found". :/ > > > > Removing the __noreturn__ attribute from abort's declaration seems > > like a pretty good idea if it makes core files usable. It's not like > > adding one instruction and taking up one word of stack space is really > > worth the sacrifice in the case of abort(). Premature optimization > > rears it's ugly head once again... ;) > > I would say the same thing about **ALL** noreturn functions, even > exit. For instance if exit crashes (e.g. closing stdio files or > running atexit handlers) you probably want to be able to see where it > was called from...
putting that under a debug knob might be fine, but by default, noreturn makes a lot more sense (bloating the code just for debugging? yikes). have you tried not writing crashy code ? :P -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc