-----Joseph Myers <jos...@codesourcery.com> wrote: ----- >On Wed, 13 Jun 2012, Fredrik Hederstierna 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.
> What do you mean by "dependencies to libunwind"? > As I explained, libunwind is a separate library that GCC > should never be building or using for platforms other than IA64 > GNU/Linux. The _Uwind_* functions are *not* libunwind functions on > ARM EABI, they are functions from libgcc_eh. Ah, ok, now I understand. The problem is rather the new dependency from libgcc to libgcc_eh then. My mistake, I thought UnWind-calls was related to libunwind, but as you explained now its libgcc_eh. Sorry for my ignorance. So, since we build toolchain with --disable-shared, the libgcc_eh.a will not be built. This makes linking to libgcc_eh not possible. Somehow also when building libgcc with -fexceptions it will make references to abort() and memcpy(), but this is maybe related. > The __aeabi_unwind_cpp_pr* personality routines are *not* libunwind >functions either, they are also functions from libgcc_eh. Anything >related to those functions should not use the term "libunwind", >whether in configure option names, or patch submissions, since it is >not libunwind. Linking with libgcc_eh should work fine by default; >no special action should be needed to link in whatever unwind >functions your code references. But if you don't want to link them >in at all, and if defining your own versions of __aeabi_div0 / >__aeabi_ldiv0 doesn't suffice, then as long as your code doesn't >raise exceptions it should be safe for you to stub out the >__aeabi_unwind_cpp_pr* functions. Ok, so the solution for us it to stub out the __aeabi_unwind_cpp_pr* functions then. This seems to me as a hack, since we build just a plain C bare-metal GCC, I would rather see a solution where dependencies to libgcc_eh could be removed completely. Something like the suggested patches, but then with renaming of 'libunwind' to 'libgcc_eh'. Thanks and Best Regards, Fredrik
