-----Joseph Myers <jos...@codesourcery.com> wrote: ----- >You need to provide a self-contained explanation of what the problem >is that your patch is fixing and why you chose that approach to >fixing it - with reference to the ARM EABI documentes (RTABI etc.) >for why your approach is valid according to the ARM EABI. libunwind >is a library separate from libgcc that is used by libgcc for >unwinding on ia64-linux-gnu only (whether built by GCC or separately >installed). There is also a separate libunwind project that may be >used on GNU/Linux platforms but I am not aware of being used for >bare-metal at all.
Our experience is that when using simple integer division in your code, the libgcc division routine will includes div-zero handling (exception support?), which will include dependencies to libunwind. This dependency problem is the background of the patch. Since libunwind does use eg. memcpy() and abort() we cannot link since we have our own custom versions of all libc functions, a real bare-metal toolchain. >Certainly it would be unusual to use it for ARM >EABI and the ARM EABI libgcc works fine without it. So referring to >libunwind in the ARM EABI context seems rather confusing; if you >don't want it, just do the same as almost all other ARM EABI users >and don't use it; it's *using* libunwind that requires special >action, not avoiding it. We don't use it, and we do not want to use it. But we use division libc functions. And the the libgcc division functions are compiled with -fexceptions, so we will get libunwind dependecies anyway. The patch does make this dependency optional. If you want I can submit you with some example scripts how we build our toolchain and some simple code to show what is our problem. (You can also check the Rockbox project that have the same problem. See previous posts from other people.) Best Regards Fredrik Hederstierna
