Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
You are absolutely right, I forgot to change this as well. Thanks! And I really really do hope that this patch will go into GCC 4.8 trunk. Since arm-elf is marked 'obsolete' in GCC 4.7, all old bare-metal arm-elf-users will need to migrate to the the new arm-eabi-toolchain in GCC 4.8.0. I fear it will cause a lot of people trouble, if we can't build a real pure bare-metal toolchain on arm-eabi target. I have not seen many comments on the patch from the community yet. Hopefully some arm-eabi maintainer will get his/her eyes on it eventually. Thanks! and Best Regards Fredrik -Larry Doolittle wrote: - To: gcc-patches@gcc.gnu.org From: Larry Doolittle Date: 06/03/2012 06:35PM Cc: Fredrik Hederstierna Subject: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind This is an update to Fredrik Hederstierna's mail and patch from 12 Apr 2012. I think he missed one place where -fexceptions needs to be changed to -fno-exceptions. With the attached patch, two of us (a friend and I, one on Linux and one on Mac) can build Rockbox with gcc-4.7.0. I'll admit I haven't checked the repository for changes in this area, this patch is based on stock released gcc-4.7.0. I have no opinion on Sebastian Huber's idea of making functionality of this kind implicit with target. - Larry [attachment "libgcc-4.7.0-baremetal.patch" removed by Fredrik Hederstierna/INT/SE/DIR/SECURITAS]
Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
-Joseph Myers 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
Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
This is the link to the original patch. It contains some background information and more links. http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00720.html The patch is now updated and improved by Larry Doolittle. /Fredrik
Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
-Joseph Myers 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
Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
> 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. -- Joseph S. Myers Ok, just read the "Exception Handling ABI for the ARM Architecture". * From Section 6.2 "Bits 24-27 select one of 16 personality routines defined by the run-time support code. Remaining bytes are data for that personality routine. ... ARM has allocated index numbers 0, 1 and 2 for use by C and C++. ... Object producers must emit an R_ARM_NONE relocation from an exception-handling table section to the required personality routine to indicate the dependency to the linker." I think you are right, we need to stub out the __aeabi_unwind_cpp_pr functions. Thanks alot & Best Regards Fredrik
[PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
We've been using a bare-metal 'arm-elf' cross-compiler toolchain over the years since GCC 2.95.x/GCC3/GCC4, and it has worked fine. Now it seems though like the 'arm-elf' target seems obsolete, and we are trying to switch to 'arm-none-eabi'. Though we use no standard-libs at all, we are really hard bare-metal with our own memcpy() implementation etc. Now when we try to build GCC 4.7.0 we get errors that libgcc has dependencies on UnWind stuff we cannot get rid of. The dependencies are caused by some division library functions like _divdi3 that can throw exceptions like division-by-zero. These exceptions I guess mainly targeting C++/Java exceptions, and we want to avoid dependencies to libunwind when building libgcc for our bare-metal pure C-toolchain. I attach a patch that adds an option to configure to avoid building libgcc with libunwind dependencies. The new option is called '--disable-libunwind-exceptions'. Over the years several people have experienced the same problem, here is some background from the gcc mailinglists: http://gcc.gnu.org/ml/gcc-help/2012-03/msg00352.html http://gcc.gnu.org/ml/gcc-help/2009-10/msg00302.html Please review and comment! Best Regards, Fredrik Hederstierna Securitas Direct AB Malmoe Sweden disable_libunwind_exceptions.patch Description: Binary data
