[PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Julian Brown]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

This patch sets compilation flags for the relevant parts of libgcc on
ARM such that the unwinder is not unnecessarily pulled in to the linked
executable when 64-bit division is used. This can be quite a
significant space saving on bare-metal systems.

Cross-tested on ARM EABI, and verified with a test program which
performs 64-bit division. OK to apply?

Julian

ChangeLog

    libgcc/
    * config.host (arm*-*-linux*, arm*-*-uclinux*, arm*-*-eabi*)
    (arm*-*-symbianelf): Add arm/t-divmod-ef to tmake_file.
    * Makefile.in (LIB2_DIVMOD_EXCEPTION_FLAGS): Set to previous
    default if not set by a target-specific Makefile fragment.
    (lib2-divmod-o, lib2-divmod-s-o): Use above.
    * config/arm/t-divmod-ef: New.
    * shared-object.mk (c_flags-$(base)$(objext)): New.
    ($(base)$(objext)): Use above.
    * static-object.mk (c_flags-$(base)$(objext)): New.
    ($(base)$(objext)): Use above.

[-- Attachment #2: no-unwinder-for-long-division-fsf-1.diff --]
[-- Type: text/x-patch, Size: 3142 bytes --]

Index: libgcc/shared-object.mk
===================================================================
--- libgcc/shared-object.mk	(revision 153062)
+++ libgcc/shared-object.mk	(working copy)
@@ -8,11 +8,13 @@ base := $(basename $(notdir $o))
 
 ifeq ($(suffix $o),.c)
 
+c_flags-$(base)$(objext) := $(c_flags)
 $(base)$(objext): $o
-	$(gcc_compile) $(c_flags) -c $< $(vis_hide)
+	$(gcc_compile) $(c_flags-$@) -c $< $(vis_hide)
 
+c_flags-$(base)_s$(objext) := $(c_flags)
 $(base)_s$(objext): $o
-	$(gcc_s_compile) $(c_flags) -c $<
+	$(gcc_s_compile) $(c_flags-$@) -c $<
 
 else
 
Index: libgcc/config.host
===================================================================
--- libgcc/config.host	(revision 153062)
+++ libgcc/config.host	(working copy)
@@ -205,12 +205,15 @@ arm*-*-netbsdelf*)
 arm*-*-netbsd*)
 	;;
 arm*-*-linux*)			# ARM GNU/Linux with ELF
+	tmake_file="${tmake_file} arm/t-divmod-ef"
 	;;
 arm*-*-uclinux*)		# ARM ucLinux
+	tmake_file="${tmake_file} arm/t-divmod-ef"
 	;;
 arm*-*-ecos-elf)
 	;;
 arm*-*-eabi* | arm*-*-symbianelf* )
+	tmake_file="${tmake_file} arm/t-divmod-ef"
 	;;
 arm*-*-rtems*)
 	;;
Index: libgcc/static-object.mk
===================================================================
--- libgcc/static-object.mk	(revision 153062)
+++ libgcc/static-object.mk	(working copy)
@@ -8,8 +8,9 @@ base := $(basename $(notdir $o))
 
 ifeq ($(suffix $o),.c)
 
+c_flags-$(base)$(objext) := $(c_flags)
 $(base)$(objext): $o
-	$(gcc_compile) $(c_flags) -c $< $(vis_hide)
+	$(gcc_compile) $(c_flags-$@) -c $< $(vis_hide)
 
 else
 
Index: libgcc/Makefile.in
===================================================================
--- libgcc/Makefile.in	(revision 153062)
+++ libgcc/Makefile.in	(working copy)
@@ -400,18 +400,24 @@ libgcc-s-objects += $(patsubst %,%_s$(ob
 endif
 endif
 
+ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
+# Provide default flags for compiling divmod functions, if they haven't been
+# set already by a target-specific Makefile fragment.
+LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
+endif
+
 # Build LIB2_DIVMOD_FUNCS.
 lib2-divmod-o = $(patsubst %,%$(objext),$(LIB2_DIVMOD_FUNCS))
 $(lib2-divmod-o): %$(objext): $(gcc_srcdir)/libgcc2.c
 	$(gcc_compile) -DL$* -c $(gcc_srcdir)/libgcc2.c \
-	  -fexceptions -fnon-call-exceptions $(vis_hide)
+	  $(LIB2_DIVMOD_EXCEPTION_FLAGS) $(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): $(gcc_srcdir)/libgcc2.c
 	$(gcc_s_compile) -DL$* -c $(gcc_srcdir)/libgcc2.c \
-	  -fexceptions -fnon-call-exceptions
+	  $(LIB2_DIVMOD_EXCEPTION_FLAGS)
 libgcc-s-objects += $(lib2-divmod-s-o)
 endif
 
Index: libgcc/config/arm/t-divmod-ef
===================================================================
--- libgcc/config/arm/t-divmod-ef	(revision 0)
+++ libgcc/config/arm/t-divmod-ef	(revision 0)
@@ -0,0 +1,4 @@
+# On ARM, specifying -fnon-call-exceptions will needlessly pull in
+# the unwinder in simple programs which use 64-bit division.  Omitting
+# the option is safe.
+LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Ian Lance Taylor]

Julian Brown <julian@codesourcery.com> writes:

> This patch sets compilation flags for the relevant parts of libgcc on
> ARM such that the unwinder is not unnecessarily pulled in to the linked
> executable when 64-bit division is used. This can be quite a
> significant space saving on bare-metal systems.
>
> Cross-tested on ARM EABI, and verified with a test program which
> performs 64-bit division. OK to apply?

I think the question here is what should happen when a division by
zero occurs.  I believe that is why we currently pass
-fnon-call-exceptions.  What happens on ARM if you divide by zero?  In
particular, what happens if you divide by zero in a program which is
itself compiled with -fnon-call-exceptions, and which expects to catch
a division by zero exception?  Do 32-bit divisions and 64-bit
divisions behave in the same way?

Ian

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Julian Brown]

On Wed, 28 Oct 2009 07:49:18 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Julian Brown <julian@codesourcery.com> writes:
> 
> > This patch sets compilation flags for the relevant parts of libgcc
> > on ARM such that the unwinder is not unnecessarily pulled in to the
> > linked executable when 64-bit division is used. This can be quite a
> > significant space saving on bare-metal systems.
> 
> I think the question here is what should happen when a division by
> zero occurs.  I believe that is why we currently pass
> -fnon-call-exceptions.  What happens on ARM if you divide by zero?  In
> particular, what happens if you divide by zero in a program which is
> itself compiled with -fnon-call-exceptions, and which expects to catch
> a division by zero exception?  Do 32-bit divisions and 64-bit
> divisions behave in the same way?

A follow-up patch to address division-by-zero problems (the handling
not being ARM EABI-compliant) is here:

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

(These patches both date from some time ago: I believe throwing an
exception from a divide-by-zero handler should work correctly after
the latter patch is applied, but I've not tested that recently.)

Julian

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Ian Lance Taylor]

Julian Brown <julian@codesourcery.com> writes:

> On Wed, 28 Oct 2009 07:49:18 -0700
> Ian Lance Taylor <iant@google.com> wrote:
>
>> Julian Brown <julian@codesourcery.com> writes:
>> 
>> > This patch sets compilation flags for the relevant parts of libgcc
>> > on ARM such that the unwinder is not unnecessarily pulled in to the
>> > linked executable when 64-bit division is used. This can be quite a
>> > significant space saving on bare-metal systems.
>> 
>> I think the question here is what should happen when a division by
>> zero occurs.  I believe that is why we currently pass
>> -fnon-call-exceptions.  What happens on ARM if you divide by zero?  In
>> particular, what happens if you divide by zero in a program which is
>> itself compiled with -fnon-call-exceptions, and which expects to catch
>> a division by zero exception?  Do 32-bit divisions and 64-bit
>> divisions behave in the same way?
>
> A follow-up patch to address division-by-zero problems (the handling
> not being ARM EABI-compliant) is here:
>
>   http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01661.html
>
> (These patches both date from some time ago: I believe throwing an
> exception from a divide-by-zero handler should work correctly after
> the latter patch is applied, but I've not tested that recently.)

Well, I'll let the ARM maintainers decide about that patch.

Looking again at
    http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html
I don't understand why you want to change shared-object.mk or
static-object.mk.

I'll approve the change to libgcc/Makefile.in if the ARM maintainers
approve the rest of the patch.

Ian

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Daniel Jacobowitz]

Catching up on mail...

On Wed, Oct 28, 2009 at 10:26:01AM -0700, Ian Lance Taylor wrote:
> Looking again at
>     http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html
> I don't understand why you want to change shared-object.mk or
> static-object.mk.
> 
> I'll approve the change to libgcc/Makefile.in if the ARM maintainers
> approve the rest of the patch.

This part is somewhat my fault; I can explain it.

A variable in the body of the rule is expanded when the rule is run,
not when the rule is defined (unlike a variable in the target or
dependencies).  The changes to *-object.mk save $(c_flags) when the
rule is defined.

From Makefile.in:

c_flags :=
iter-items := $(LIB2ADD) $(LIB2ADD_ST)
include $(iterator)

...

c_flags := -fexceptions
iter-items := $(sort $(LIB2ADDEHSTATIC) $(LIB2ADDEHSHARED))
include $(iterator)

Take a look at a libgcc build log.  We're using -fexceptions for more
than was intended.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Ian Lance Taylor]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Oct 28, 2009 at 10:26:01AM -0700, Ian Lance Taylor wrote:
>> Looking again at
>>     http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html
>> I don't understand why you want to change shared-object.mk or
>> static-object.mk.
>> 
>> I'll approve the change to libgcc/Makefile.in if the ARM maintainers
>> approve the rest of the patch.
>
> This part is somewhat my fault; I can explain it.
>
> A variable in the body of the rule is expanded when the rule is run,
> not when the rule is defined (unlike a variable in the target or
> dependencies).  The changes to *-object.mk save $(c_flags) when the
> rule is defined.
>
>From Makefile.in:
>
> c_flags :=
> iter-items := $(LIB2ADD) $(LIB2ADD_ST)
> include $(iterator)
>
> ...
>
> c_flags := -fexceptions
> iter-items := $(sort $(LIB2ADDEHSTATIC) $(LIB2ADDEHSHARED))
> include $(iterator)
>
> Take a look at a libgcc build log.  We're using -fexceptions for more
> than was intended.

Hmmm, OK, but I still don't see what that part of the patch has to do
with the rest of the patch.  What sets c_flags-$@?

Ian

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Paolo Bonzini]

On 11/13/2009 05:51 PM, Ian Lance Taylor wrote:
> Hmmm, OK, but I still don't see what that part of the patch has to do
> with the rest of the patch.  What sets c_flags-$@?

This:

+c_flags-$(base)$(objext) := $(c_flags)

That part of the patch is okay.  The libgcc makefile is much more 
imperative than your usual makefile, so using := is the right thing to do.

Paolo

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Julian Brown]

On Wed, 28 Oct 2009 10:26:01 -0700
Ian Lance Taylor <iant@google.com> wrote:

> I'll approve the change to libgcc/Makefile.in if the ARM maintainers
> approve the rest of the patch.

Ping (for ARM parts)?

Julian

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Paul Brook]

On Tuesday 27 October 2009, Julian Brown wrote:
> This patch sets compilation flags for the relevant parts of libgcc on
> ARM such that the unwinder is not unnecessarily pulled in to the linked
> executable when 64-bit division is used. This can be quite a
> significant space saving on bare-metal systems.

Do we want to be using -fexceptions at all? My guess is this works mostly by 
chance because all the routines in that file are leaf functions, and we should 
really remove this too. If we do have a mix of (leaf) division routines and 
code that can be throw though then I thing we need to split them into 
different files.

Might be worth noting that ARM is special because we already did the /0 checks 
in eh assembly wrappers.

Paul

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Andrew Haley]

Paul Brook wrote:
> On Tuesday 27 October 2009, Julian Brown wrote:
>> This patch sets compilation flags for the relevant parts of libgcc on
>> ARM such that the unwinder is not unnecessarily pulled in to the linked
>> executable when 64-bit division is used. This can be quite a
>> significant space saving on bare-metal systems.
> 
> Do we want to be using -fexceptions at all? My guess is this works mostly by 
> chance because all the routines in that file are leaf functions, and we should 
> really remove this too.

I added -fexceptions -fnon-call-exceptions to those files back in 2001
in order to make it possible to catch exceptions on division by zero.

> If we do have a mix of (leaf) division routines and 
> code that can be throw though then I thing we need to split them into 
> different files.
> 
> Might be worth noting that ARM is special because we already did the /0 checks 
> in eh assembly wrappers.

OK.  I'm presuming (hoping?) that these changes for ARM aren't going to
break the exception handling, although I have no idea how.

Andrew.

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Paul Brook]

> > If we do have a mix of (leaf) division routines and
> > code that can be throw though then I thing we need to split them into
> > different files.
> >
> > Might be worth noting that ARM is special because we already did the /0
> > checks in eh assembly wrappers.
> 
> OK.  I'm presuming (hoping?) that these changes for ARM aren't going to
> break the exception handling, although I have no idea how.

ARM is special:

* -fnon-call-exceptions probably doesn't work reliably. The ARM unwind tables 
only allow a single stack frame definition for the whole function. This 
probably doesn't matter so much in this context

* All ARM unwinding tables pull in a personality routine and a large chunk of 
the unwinder. c.f. most other GCC targets where unwinder is independent, and 
the personality routines are only pulled in if you have cleanup/catch 
handlers. This may be fixable in binutils, but for now means we're much more 
sensitive to superfluous unwinding tables.

* To avoid the above two issues the ARM division routines are implemented as 
an assembly wrapper that checks for division by zero and tailcalls the 
appropriate EABI defined handler. This ensures the actual division code will 
never encounter exceptions.

Paul

Re: [PATCH, ARM] Avoid pulling in unwinder for 64-bit division

[Andrew Haley]

Paul Brook wrote:
>>> If we do have a mix of (leaf) division routines and
>>> code that can be throw though then I thing we need to split them into
>>> different files.
>>>
>>> Might be worth noting that ARM is special because we already did the /0
>>> checks in eh assembly wrappers.
>> OK.  I'm presuming (hoping?) that these changes for ARM aren't going to
>> break the exception handling, although I have no idea how.
> 
> ARM is special:
> 
> * -fnon-call-exceptions probably doesn't work reliably. The ARM unwind tables 
> only allow a single stack frame definition for the whole function. This 
> probably doesn't matter so much in this context

Ah, now you mention it, I seem to remember that we don't use
-fnon-call-exceptions on ARM in libgcj.  I thought the real
reason was that we'd never got around to doing it, but maybe not.

:-)

Andrew.