On Thu, 17 Nov 2011, Mike Frysinger wrote:
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.
If it's just another register or couple of registers that need to be
pushed, it doesn't necessarily have to mean an increase in code size,
although execution time will be longer.
Quite frankly, one could take a couple of more or less typical
applications and see what the difference would be in practice.
I agree that debugging functions should normally not be enabled in
production code, still, it could be very useful to be able to do
post-mortem debugging on a crashed application, especially if the
conditions which make it crash are neigh impossible to figure out and
set up so that reproduction becomes a nightmare. In such cases being able
to see why an application crashed can be a godsend and very likely worth
the overhead.
Having it switchable on/off would of course be fine in the spirit of the
rest of the configurability of uClibc.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
