On Fri, Nov 04, 2011 at 03:08:25AM +0000, Grant Edwards wrote: > On 2011-11-04, Rich Felker <[email protected]> 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... Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
