>> We generate the map-file, the content tells that (if I understand correctly)
>>
>> "_divdi3.o" use "__aeabi_unwind_cpp_pr0" which resides in "unwind-arm.o".
>>
>> Is it really correct that we need unwind-support if just using division?
>> Could it be that _divdi3 can 'throw' division-by-zero 'exception' ?
>> (We have overloaded div0: "void __div0(void) { assert(0); }" so we dont want unwinding here anyway...)
>
>I suspect (but you'll have to check) that this is because _divdi3 is
>compiled with exceptions, and this is indeed because division by zero
>might throw. The simplest fix is to compile it without exceptions.
>The correct fix is to make unwinding work on your platform.
Sorry I don't fully agree, we don't want the unwinding stuff.
We are very short on flash memory, and we do not want to waste bytes on unnecessary code.
Also, why does it work with 'arm-none-elf', shouldn't it be the same regarding __div0?
The correct solution would be to exclude dependency to unwind from _divdi3 when building a bare metal toolchain.
Thanks to Thomas Martitz for the proposed patch.
This patch makes libgcc to be compiled with "-fno-exception" instead of "-fexception".
I propose an even better patch maybe to re-introduce a configure option alike "--disable-libunwind-exceptions" or similar.
This configuration option could control this "-f(no)-exception" flag when compiling GCC toolchain.
Then it could be optional for the developer to be able to exclude the exceptions on a extreme bare metal toolchain.
If you think such a patch would be accepted by the community, I could think of spending some time to fix it myself.
Thanks for you feedback and help, its most appreciated!
/Fredrik Hederstierna
