On Thursday 17 November 2011 14:33:16 Grant Edwards wrote: > On 2011-11-17, Mike Frysinger <[email protected]> wrote: > > 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 <[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... > > > > 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). > > Bloat? It's _one_ flipping instruction! (Two if you do it for exit() > and abort()).
incorrect -- you're ignoring the call sites. by assuming the call never returns, it means the caller doesn't have to waste time saving/restoring state. it can also make a difference to DCE. > > have you tried not writing crashy code ? :P > > It's not a "crashy code". It's a way to generate a traceback for fatal > events. based on other responses, sounds like your toolchain needs work independent of uClibc. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
