On Sunday 20 November 2011 15:13:17 Grant Edwards wrote: > On 2011-11-17, Mike Frysinger wrote: > >> 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). > > After removing __noreturn__ from abort() my complete > kernel+rootfs+apps uImage size (compressed) increased from 7373224 > bytes to 7373412 bytes. That's a change of 188 bytes out of 7.3 > million, or 0.0025%.
it also introduces wrong warnings to valid code:
int foo(int j) {
int i;
if (j < 100)
abort();
else
i = 100;
return j - i;
}
w/out noreturn attribute, "i" gets warned about because it's used
uninitialized. yes, this is a contrived example, but it's trivial to see how
this is used in real world code. try disabling BUG() in the kernel and look
at all the build warnings due to that.
> Not really a lot of "bloat", but it's apparently a moot point now: I
> filed a bug requesting that the __noreturn__ attribute be removed from
> abourt() so that it produces backtraceable core files, but the bug has
> been declared "invalid".
yes, because from the perspective of uClibc, your report is invalid. there is
a bug in the toolchain, but it most likely is not from uClibc. report it to
whoever is providing your gcc/gdb ports.
-mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
