On 2011-11-20, Mike Frysinger <[email protected]> wrote:
> 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;
> }
Then put the __noreturn__ back in for the version of stdlib.h used by
that code. To fix the "no return PC" problem, all that matters is that
when the source code for abort() is compiled you don't tell gcc not to
provide a return address.
> 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.
It's plain vanilla gcc/gdb as built by crosstool-ng for ARM. Can you
recommend a different toolchain that works correctly with uClibc? Or
perhaps we shouldn't use ARM processors with uClibc?
--
Grant Edwards grant.b.edwards Yow! Awright, which one of
at you hid my PENIS ENVY?
gmail.com
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
