Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-13 Thread Fredrik Hederstierna 
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

2012-06-13 Thread Julian Brown 
On Wed, 13 Jun 2012 09:35:42 +0200
Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com wrote:

 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

Related:

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html

That one only handles 64-bit division (I don't know if there are other
things which pull in the unwinder), and is probably quite bitrotten by
now -- it never got approved/committed. Sorry about that!

Cheers,

Julian

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-13 Thread Joseph S. Myers 
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.  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
jos...@codesourcery.com

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-13 Thread Fredrik Hederstierna 


-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

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-13 Thread Fredrik Hederstierna 

 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

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-12 Thread Sebastian Huber 

On 06/12/2012 04:37 PM, Joseph S. 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.  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.


I think the main problem is the usage of -fexceptions for some libgcc files.  I 
would not disable the libunwind build and simply avoid the -fexceptions.  See also


http://gcc.gnu.org/ml/gcc-help/2011-03/msg00149.html

--
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-04 Thread Fredrik Hederstierna 
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 ldool...@recycle.lbl.gov wrote: -
To: gcc-patches@gcc.gnu.org
From: Larry Doolittle ldool...@recycle.lbl.gov
Date: 06/03/2012 06:35PM
Cc: Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com
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]

[PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-06-03 Thread Larry Doolittle 
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
diff -ur libgcc-orig/configure libgcc-baremetal/configure
--- libgcc-orig/configure	2012-01-22 22:25:28.0 -0800
+++ libgcc-baremetal/configure	2012-05-31 07:30:36.0 -0700
@@ -600,6 +600,7 @@
 set_use_emutls
 set_have_cc_tls
 vis_hide
+enable_libunwind_exceptions
 fixed_point
 enable_decimal_float
 decimal_float
@@ -697,6 +698,7 @@
 with_build_libsubdir
 enable_decimal_float
 with_system_libunwind
+enable_libunwind_exceptions
 enable_sjlj_exceptions
 enable_tls
 '
@@ -1332,6 +1334,8 @@
 			enable decimal float extension to C.  Selecting 'bid'
 			or 'dpd' choses which decimal floating point format
 			to use
+  --disable-libunwind-exceptions
+			disable use of libunwind when build libgcc
   --enable-sjlj-exceptions
   force use of builtin_setjmp for exceptions
   --enable-tlsUse thread-local storage [default=yes]
@@ -4493,6 +4497,15 @@
   fi
 
 
+# For bare metal toolchain libundwind exceptions can be disabled
+# Check whether --enable-libunwind-exceptions was given.
+if test ${enable_libunwind_exceptions+set} = set; then :
+  enableval=$enable_libunwind_exceptions; enable_libunwind_exceptions=$enableval
+else
+  enable_libunwind_exceptions=yes
+fi
+
+
 # The sjlj test is almost duplicated here and in libgo/configure.ac (for C),
 # libstdc++-v3/acinclude.m4 and libjava/configure.ac (for C++), and
 # libobjc/configure.ac (for Objective-C).
diff -ur libgcc-orig/configure.ac libgcc-baremetal/configure.ac
--- libgcc-orig/configure.ac	2011-11-07 08:34:31.0 -0800
+++ libgcc-baremetal/configure.ac	2012-05-27 11:49:22.0 -0700
@@ -184,6 +184,14 @@
 # config.gcc also contains tests of with_system_libunwind.
 GCC_CHECK_UNWIND_GETIPINFO
 
+# For bare metal toolchain libundwind exceptions can be disabled
+AC_ARG_ENABLE(libunwind-exceptions,
+  [AC_HELP_STRING([--disable-libunwind-exceptions],
+[disable use of libunwind when build libgcc])],
+  [enable_libunwind_exceptions=$enableval],
+  [enable_libunwind_exceptions=yes])
+AC_SUBST(enable_libunwind_exceptions)
+
 # The sjlj test is almost duplicated here and in libgo/configure.ac (for C),
 # libstdc++-v3/acinclude.m4 and libjava/configure.ac (for C++), and
 # libobjc/configure.ac (for Objective-C).
diff -ur libgcc-orig/Makefile.in libgcc-baremetal/Makefile.in
--- libgcc-orig/Makefile.in	2011-11-21 19:01:02.0 -0800
+++ libgcc-baremetal/Makefile.in	2012-05-29 18:45:03.0 -0700
@@ -41,6 +41,7 @@
 decimal_float = @decimal_float@
 enable_decimal_float = @enable_decimal_float@
 fixed_point = @fixed_point@
+enable_libunwind_exceptions = @enable_libunwind_exceptions@
 
 host_noncanonical = @host_noncanonical@
 target_noncanonical = @target_noncanonical@
@@ -497,17 +498,23 @@
 endif
 
 # Build LIB2_DIVMOD_FUNCS.
+ifeq ($(enable_libunwind_exceptions),yes)
+LIB2_DIVMOD_CFLAGS := -fexceptions -fnon-call-exceptions
+else
+LIB2_DIVMOD_CFLAGS := -fno-exceptions -fno-non-call-exceptions
+endif
+
 lib2-divmod-o = $(patsubst %,%$(objext),$(LIB2_DIVMOD_FUNCS))
 $(lib2-divmod-o): %$(objext): $(srcdir)/libgcc2.c
 	$(gcc_compile) -DL$* -c $ \
-	  -fexceptions -fnon-call-exceptions $(vis_hide)
+	  $(LIB2_DIVMOD_CFLAGS) $(vis_hide)
 libgcc-objects += $(lib2-divmod-o)
 
 ifeq ($(enable_shared),yes)
 lib2-divmod-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIVMOD_FUNCS))
 $(lib2-divmod-s-o): %_s$(objext): $(srcdir)/libgcc2.c
 	$(gcc_s_compile) -DL$* -c $ \
-	  -fexceptions -fnon-call-exceptions
+	  $(LIB2_DIVMOD_CFLAGS) $(vis_hide)
 libgcc-s-objects += $(lib2-divmod-s-o)
 endif
 
@@ -810,7 +817,11 @@
 # libgcc_eh.a, only LIB2ADDEH matters.  If we do, only LIB2ADDEHSTATIC and
 # LIB2ADDEHSHARED matter.  (Usually all three are identical.)
 
+ifeq ($(enable_libunwind_exceptions),yes)
 c_flags := -fexceptions
+else
+c_flags := -fno-exceptions
+endif
 
 ifeq ($(enable_shared),yes)

Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-04-13 Thread Sebastian Huber 

Hello,

I think it is good to disable the exceptions for the division by zero.  Maybe 
this should be made target specific and not based on a configure option.  For 
example in libgcc/config.host:


arm*-*-linux*)
[...]
tmake_file=${tmake_file} arm/t-div-by-zero-exc
[...]

With libgcc/config/arm/t-div-by-zero-exc:

LIB2_DIVMOD_CFLAGS := -fexceptions -fnon-call-exception

--
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

2012-04-12 Thread Fredrik Hederstierna 
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