[PATCH][Ada] arm-linux sjlj port

[PATCH][Ada] arm-linux sjlj port

[Laurent GUERBY]

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

Hi,

Using Mikael 4.4.1 armel binaries as base compiler:

http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/

And with the following updated patch from Mikael GCC trunk
bootstraps Ada successfully on arm-linux (sjlj exceptions) 
and has quite good ACATS results:

http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html

Ok to commit to trunk after a complete bootstrap+check?

Thanks in advance,

Laurent

2009-09-07  Mikael Pettersson  <mikpe@it.uu.se>

	* gcc-interface/Makefile.in: Add arm*-*-linux-gnueabi.
	* system-linux-armeb.ads, system-linux-armel.ads: New files.


[-- Attachment #2: patch-ada-arm-v2.txt --]
[-- Type: text/plain, Size: 17212 bytes --]

Index: gcc/ada/system-linux-armel.ads
===================================================================
--- gcc/ada/system-linux-armel.ads	(revision 0)
+++ gcc/ada/system-linux-armel.ads	(revision 0)
@@ -0,0 +1,153 @@
+------------------------------------------------------------------------------
+--                                                                          --
+--                        GNAT RUN-TIME COMPONENTS                          --
+--                                                                          --
+--                               S Y S T E M                                --
+--                                                                          --
+--                                 S p e c                                  --
+--                        (GNU-Linux/ARMEL Version)                         --
+--                                                                          --
+--          Copyright (C) 1992-2009, Free Software Foundation, Inc.         --
+--                                                                          --
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the  contents of the part following the private keyword. --
+--                                                                          --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE.                                     --
+--                                                                          --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.               --
+--                                                                          --
+-- You should have received a copy of the GNU General Public License and    --
+-- a copy of the GCC Runtime Library Exception along with this program;     --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see    --
+-- <http://www.gnu.org/licenses/>.                                          --
+--                                                                          --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.      --
+--                                                                          --
+------------------------------------------------------------------------------
+
+package System is
+   pragma Pure;
+   --  Note that we take advantage of the implementation permission to make
+   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+   --  2005, this is Pure in any case (AI-362).
+
+   type Name is (SYSTEM_NAME_GNAT);
+   System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+   --  System-Dependent Named Numbers
+
+   Min_Int               : constant := Long_Long_Integer'First;
+   Max_Int               : constant := Long_Long_Integer'Last;
+
+   Max_Binary_Modulus    : constant := 2 ** Long_Long_Integer'Size;
+   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+   Max_Base_Digits       : constant := Long_Long_Float'Digits;
+   Max_Digits            : constant := Long_Long_Float'Digits;
+
+   Max_Mantissa          : constant := 63;
+   Fine_Delta            : constant := 2.0 ** (-Max_Mantissa);
+
+   Tick                  : constant := 0.000_001;
+
+   --  Storage-related Declarations
+
+   type Address is private;
+   pragma Preelaborable_Initialization (Address);
+   Null_Address : constant Address;
+
+   Storage_Unit : constant := 8;
+   Word_Size    : constant := 32;
+   Memory_Size  : constant := 2 ** 32;
+
+   --  Address comparison
+
+   function "<"  (Left, Right : Address) return Boolean;
+   function "<=" (Left, Right : Address) return Boolean;
+   function ">"  (Left, Right : Address) return Boolean;
+   function ">=" (Left, Right : Address) return Boolean;
+   function "="  (Left, Right : Address) return Boolean;
+
+   pragma Import (Intrinsic, "<");
+   pragma Import (Intrinsic, "<=");
+   pragma Import (Intrinsic, ">");
+   pragma Import (Intrinsic, ">=");
+   pragma Import (Intrinsic, "=");
+
+   --  Other System-Dependent Declarations
+
+   type Bit_Order is (High_Order_First, Low_Order_First);
+   Default_Bit_Order : constant Bit_Order := Low_Order_First;
+   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+   --  Priority-related Declarations (RM D.1)
+
+   --  0 .. 98 corresponds to the system priority range 1 .. 99.
+   --
+   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+   --  of the entire range provided by the system.
+   --
+   --  If the scheduling policy is SCHED_OTHER the only valid system priority
+   --  is 1 and other values are simply ignored.
+
+   Max_Priority           : constant Positive := 97;
+   Max_Interrupt_Priority : constant Positive := 98;
+
+   subtype Any_Priority       is Integer      range  0 .. 98;
+   subtype Priority           is Any_Priority range  0 .. 97;
+   subtype Interrupt_Priority is Any_Priority range 98 .. 98;
+
+   Default_Priority : constant Priority := 48;
+
+private
+
+   type Address is mod Memory_Size;
+   Null_Address : constant Address := 0;
+
+   --------------------------------------
+   -- System Implementation Parameters --
+   --------------------------------------
+
+   --  These parameters provide information about the target that is used
+   --  by the compiler. They are in the private part of System, where they
+   --  can be accessed using the special circuitry in the Targparm unit
+   --  whose source should be consulted for more detailed descriptions
+   --  of the individual switch values.
+
+   Backend_Divide_Checks     : constant Boolean := False;
+   Backend_Overflow_Checks   : constant Boolean := False;
+   Command_Line_Args         : constant Boolean := True;
+   Configurable_Run_Time     : constant Boolean := False;
+   Denorm                    : constant Boolean := True;
+   Duration_32_Bits          : constant Boolean := False;
+   Exit_Status_Supported     : constant Boolean := True;
+   Fractional_Fixed_Ops      : constant Boolean := False;
+   Frontend_Layout           : constant Boolean := False;
+   Machine_Overflows         : constant Boolean := False;
+   Machine_Rounds            : constant Boolean := True;
+   Preallocated_Stacks       : constant Boolean := False;
+   Signed_Zeros              : constant Boolean := True;
+   Stack_Check_Default       : constant Boolean := False;
+   Stack_Check_Probes        : constant Boolean := False;
+   Stack_Check_Limits        : constant Boolean := False;
+   Support_64_Bit_Divides    : constant Boolean := True;
+   Support_Aggregates        : constant Boolean := True;
+   Support_Composite_Assign  : constant Boolean := True;
+   Support_Composite_Compare : constant Boolean := True;
+   Support_Long_Shifts       : constant Boolean := True;
+   Always_Compatible_Rep     : constant Boolean := False;
+   Suppress_Standard_Library : constant Boolean := False;
+   Use_Ada_Main_Program_Name : constant Boolean := False;
+   ZCX_By_Default            : constant Boolean := False;
+   GCC_ZCX_Support           : constant Boolean := False;
+
+end System;
Index: gcc/ada/gcc-interface/Makefile.in
===================================================================
--- gcc/ada/gcc-interface/Makefile.in	(revision 151474)
+++ gcc/ada/gcc-interface/Makefile.in	(working copy)
@@ -1815,6 +1815,43 @@
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
+# arm*-*-linux-gnueabi
+ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ)))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.ads<a-intnam-linux.ads \
+  s-inmaop.adb<s-inmaop-posix.adb \
+  s-intman.adb<s-intman-posix.adb \
+  s-linux.ads<s-linux.ads \
+  s-osinte.adb<s-osinte-posix.adb \
+  s-osinte.ads<s-osinte-linux.ads \
+  s-osprim.adb<s-osprim-posix.adb \
+  s-taprop.adb<s-taprop-linux.adb \
+  s-tasinf.ads<s-tasinf-linux.ads \
+  s-tasinf.adb<s-tasinf-linux.adb \
+  s-taspri.ads<s-taspri-posix-noaltstack.ads \
+  s-tpopsp.adb<s-tpopsp-posix-foreign.adb
+
+  ifeq ($(strip $(filter-out arm%b,$(arch))),)
+    LIBGNAT_TARGET_PAIRS += \
+    system.ads<system-linux-armeb.ads
+  else
+    LIBGNAT_TARGET_PAIRS += \
+    system.ads<system-linux-armel.ads
+  endif
+
+  TOOLS_TARGET_PAIRS =  \
+    mlib-tgt-specific.adb<mlib-tgt-specific-linux.adb \
+    indepsw.adb<indepsw-gnu.adb
+
+  EXTRA_GNATRTL_TASKING_OBJS=s-linux.o
+  EH_MECHANISM=
+  THREADSLIB = -lpthread
+  GNATLIB_SHARED = gnatlib-shared-dual
+  GMEM_LIB = gmemlib
+  PREFIX_OBJS = $(PREFIX_REAL_OBJS)
+  LIBRARY_VERSION := $(LIB_VERSION)
+endif
+
 ifeq ($(strip $(filter-out sparc% linux%,$(arch) $(osys))),)
   LIBGNAT_TARGET_PAIRS_COMMON = \
   a-intnam.ads<a-intnam-linux.ads \
Index: gcc/ada/system-linux-armeb.ads
===================================================================
--- gcc/ada/system-linux-armeb.ads	(revision 0)
+++ gcc/ada/system-linux-armeb.ads	(revision 0)
@@ -0,0 +1,153 @@
+------------------------------------------------------------------------------
+--                                                                          --
+--                        GNAT RUN-TIME COMPONENTS                          --
+--                                                                          --
+--                               S Y S T E M                                --
+--                                                                          --
+--                                 S p e c                                  --
+--                        (GNU-Linux/ARMEB Version)                         --
+--                                                                          --
+--          Copyright (C) 1992-2009, Free Software Foundation, Inc.         --
+--                                                                          --
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the  contents of the part following the private keyword. --
+--                                                                          --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE.                                     --
+--                                                                          --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.               --
+--                                                                          --
+-- You should have received a copy of the GNU General Public License and    --
+-- a copy of the GCC Runtime Library Exception along with this program;     --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see    --
+-- <http://www.gnu.org/licenses/>.                                          --
+--                                                                          --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.      --
+--                                                                          --
+------------------------------------------------------------------------------
+
+package System is
+   pragma Pure;
+   --  Note that we take advantage of the implementation permission to make
+   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+   --  2005, this is Pure in any case (AI-362).
+
+   type Name is (SYSTEM_NAME_GNAT);
+   System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+   --  System-Dependent Named Numbers
+
+   Min_Int               : constant := Long_Long_Integer'First;
+   Max_Int               : constant := Long_Long_Integer'Last;
+
+   Max_Binary_Modulus    : constant := 2 ** Long_Long_Integer'Size;
+   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+   Max_Base_Digits       : constant := Long_Long_Float'Digits;
+   Max_Digits            : constant := Long_Long_Float'Digits;
+
+   Max_Mantissa          : constant := 63;
+   Fine_Delta            : constant := 2.0 ** (-Max_Mantissa);
+
+   Tick                  : constant := 0.000_001;
+
+   --  Storage-related Declarations
+
+   type Address is private;
+   pragma Preelaborable_Initialization (Address);
+   Null_Address : constant Address;
+
+   Storage_Unit : constant := 8;
+   Word_Size    : constant := 32;
+   Memory_Size  : constant := 2 ** 32;
+
+   --  Address comparison
+
+   function "<"  (Left, Right : Address) return Boolean;
+   function "<=" (Left, Right : Address) return Boolean;
+   function ">"  (Left, Right : Address) return Boolean;
+   function ">=" (Left, Right : Address) return Boolean;
+   function "="  (Left, Right : Address) return Boolean;
+
+   pragma Import (Intrinsic, "<");
+   pragma Import (Intrinsic, "<=");
+   pragma Import (Intrinsic, ">");
+   pragma Import (Intrinsic, ">=");
+   pragma Import (Intrinsic, "=");
+
+   --  Other System-Dependent Declarations
+
+   type Bit_Order is (High_Order_First, Low_Order_First);
+   Default_Bit_Order : constant Bit_Order := High_Order_First;
+   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+   --  Priority-related Declarations (RM D.1)
+
+   --  0 .. 98 corresponds to the system priority range 1 .. 99.
+   --
+   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+   --  of the entire range provided by the system.
+   --
+   --  If the scheduling policy is SCHED_OTHER the only valid system priority
+   --  is 1 and other values are simply ignored.
+
+   Max_Priority           : constant Positive := 97;
+   Max_Interrupt_Priority : constant Positive := 98;
+
+   subtype Any_Priority       is Integer      range  0 .. 98;
+   subtype Priority           is Any_Priority range  0 .. 97;
+   subtype Interrupt_Priority is Any_Priority range 98 .. 98;
+
+   Default_Priority : constant Priority := 48;
+
+private
+
+   type Address is mod Memory_Size;
+   Null_Address : constant Address := 0;
+
+   --------------------------------------
+   -- System Implementation Parameters --
+   --------------------------------------
+
+   --  These parameters provide information about the target that is used
+   --  by the compiler. They are in the private part of System, where they
+   --  can be accessed using the special circuitry in the Targparm unit
+   --  whose source should be consulted for more detailed descriptions
+   --  of the individual switch values.
+
+   Backend_Divide_Checks     : constant Boolean := False;
+   Backend_Overflow_Checks   : constant Boolean := False;
+   Command_Line_Args         : constant Boolean := True;
+   Configurable_Run_Time     : constant Boolean := False;
+   Denorm                    : constant Boolean := True;
+   Duration_32_Bits          : constant Boolean := False;
+   Exit_Status_Supported     : constant Boolean := True;
+   Fractional_Fixed_Ops      : constant Boolean := False;
+   Frontend_Layout           : constant Boolean := False;
+   Machine_Overflows         : constant Boolean := False;
+   Machine_Rounds            : constant Boolean := True;
+   Preallocated_Stacks       : constant Boolean := False;
+   Signed_Zeros              : constant Boolean := True;
+   Stack_Check_Default       : constant Boolean := False;
+   Stack_Check_Probes        : constant Boolean := False;
+   Stack_Check_Limits        : constant Boolean := False;
+   Support_64_Bit_Divides    : constant Boolean := True;
+   Support_Aggregates        : constant Boolean := True;
+   Support_Composite_Assign  : constant Boolean := True;
+   Support_Composite_Compare : constant Boolean := True;
+   Support_Long_Shifts       : constant Boolean := True;
+   Always_Compatible_Rep     : constant Boolean := False;
+   Suppress_Standard_Library : constant Boolean := False;
+   Use_Ada_Main_Program_Name : constant Boolean := False;
+   ZCX_By_Default            : constant Boolean := False;
+   GCC_ZCX_Support           : constant Boolean := False;
+
+end System;

Re: [PATCH][Ada] arm-linux sjlj port

[Richard Earnshaw]

On Mon, 2009-09-07 at 12:25 +0200, Laurent GUERBY wrote:
> Hi,
> 
> Using Mikael 4.4.1 armel binaries as base compiler:
> 
> http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/
> 
> And with the following updated patch from Mikael GCC trunk
> bootstraps Ada successfully on arm-linux (sjlj exceptions) 
> and has quite good ACATS results:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html
> 
> Ok to commit to trunk after a complete bootstrap+check?
> 

Although this patch is completely in the Ada backend, and thus has very
little to do with the ARM port maintenance, I'm concerned that we are
trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
Why aren't we using the unwind tables?

Having an SJLJ port (in addition to being very poor performance) seems
the wrong way to go to me, as it will just cause confusion for our
users.

R.

Re: [PATCH][Ada] arm-linux sjlj port

[Arnaud Charlet]

> Although this patch is completely in the Ada backend, and thus has very
> little to do with the ARM port maintenance, I'm concerned that we are
> trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> Why aren't we using the unwind tables?
> 
> Having an SJLJ port (in addition to being very poor performance) seems
> the wrong way to go to me, as it will just cause confusion for our
> users.

I share this concern.
Also, do we really need *two* ports (little and big endian)?
Are they users for these two ports? And is there someone willing to "maintain"
these ports when needed? My other concern is to avoid having ports that are not
really built/maintained and that will quickly bit rot over time.

Arno

Re: [PATCH][Ada] arm-linux sjlj port

[Richard Earnshaw]

On Mon, 2009-09-07 at 12:40 +0200, Arnaud Charlet wrote:
> > Although this patch is completely in the Ada backend, and thus has very
> > little to do with the ARM port maintenance, I'm concerned that we are
> > trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> > Why aren't we using the unwind tables?
> > 
> > Having an SJLJ port (in addition to being very poor performance) seems
> > the wrong way to go to me, as it will just cause confusion for our
> > users.
> 
> I share this concern.
> Also, do we really need *two* ports (little and big endian)?

People using big-endian systems object to having to modify their build
scripts to put -mbig-endian into every command.  I agree this is a pain,
but ARM (the core CPU) is pretty agnostic to the endianness of the
system it is used in and it is used in both worlds (though by far the
majority tend to use it in a little-endian world).   Unfortunately, I
can't just ignore that constituency.

R.

Re: [PATCH][Ada] arm-linux sjlj port

[Laurent GUERBY]

On Mon, 2009-09-07 at 11:33 +0100, Richard Earnshaw wrote:
> On Mon, 2009-09-07 at 12:25 +0200, Laurent GUERBY wrote:
> > Hi,
> > 
> > Using Mikael 4.4.1 armel binaries as base compiler:
> > 
> > http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/
> > 
> > And with the following updated patch from Mikael GCC trunk
> > bootstraps Ada successfully on arm-linux (sjlj exceptions) 
> > and has quite good ACATS results:
> > 
> > http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html
> > 
> > Ok to commit to trunk after a complete bootstrap+check?
> > 
> 
> Although this patch is completely in the Ada backend, and thus has very
> little to do with the ARM port maintenance, I'm concerned that we are
> trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> Why aren't we using the unwind tables?
> 
> Having an SJLJ port (in addition to being very poor performance) seems
> the wrong way to go to me, as it will just cause confusion for our
> users.

A non-SJLJ (ZCX in Ada terminology) port would need someone writting the
personality routine for Ada, that is to say add some stuff in
gcc/ada/raise-gcc.c for arm EABI. I might get enough time in the future
to try to do so but I've zero experience in this area (both on the Ada
side and on the EH side) so even if the patch will likely end up
trivial it will take me a long while to figure it out.

Discussions here:

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00509.html

Following the email I sent to you in december 2008 about
a build failure on arm for Ada:

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01185.html

Sincerely,

Laurent

Re: [PATCH][Ada] arm-linux sjlj port

[Laurent GUERBY]

On Mon, 2009-09-07 at 12:40 +0200, Arnaud Charlet wrote:
> > Although this patch is completely in the Ada backend, and thus has very
> > little to do with the ARM port maintenance, I'm concerned that we are
> > trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> > Why aren't we using the unwind tables?
> > 
> > Having an SJLJ port (in addition to being very poor performance) seems
> > the wrong way to go to me, as it will just cause confusion for our
> > users.
> 
> I share this concern.
> Also, do we really need *two* ports (little and big endian)?
> Are they users for these two ports? And is there someone willing to "maintain"
> these ports when needed? My other concern is to avoid having ports that are not
> really built/maintained and that will quickly bit rot over time.

The only diff between the files is:

-   Default_Bit_Order : constant Bit_Order := Low_Order_First;
+   Default_Bit_Order : constant Bit_Order := High_Order_First;

We could use one file and:

   Default_Bit_Order : constant Bit_Order :=
                         Bit_Order'Val (Standard'Default_Bit_Order);

But you told me earlier that this style was to be avoided in system-*
files.

Up to now I've had access only to armel systems so I cannot
test the armeb side.

Sincerely,

Laurent

Re: [PATCH][Ada] arm-linux sjlj port

[Arnaud Charlet]

>    Default_Bit_Order : constant Bit_Order :=
>                          Bit_Order'Val (Standard'Default_Bit_Order);
> 
> But you told me earlier that this style was to be avoided in system-*
> files.

Right, I'm not concerned about have two files. I'm concerned about having
two ports, and nobody to build/test/maintain them (or one of)!

> Up to now I've had access only to armel systems so I cannot
> test the armeb side.

Right, that seconds my point.

Arno

Re: [PATCH][Ada] arm-linux sjlj port

[Eric Botcazou]

> Although this patch is completely in the Ada backend, and thus has very
> little to do with the ARM port maintenance, I'm concerned that we are
> trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> Why aren't we using the unwind tables?

GNAT hasn't been ported to DWARF EH for ARM, SJLJ is the only available 
solution for Ada on ARM as of this writing.

-- 
Eric Botcazou

Re: [PATCH][Ada] arm-linux sjlj port

[Mikael Pettersson]

Laurent GUERBY writes:
 > > Although this patch is completely in the Ada backend, and thus has very
 > > little to do with the ARM port maintenance, I'm concerned that we are
 > > trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
 > > Why aren't we using the unwind tables?
 > > 
 > > Having an SJLJ port (in addition to being very poor performance) seems
 > > the wrong way to go to me, as it will just cause confusion for our
 > > users.
 > 
 > A non-SJLJ (ZCX in Ada terminology) port would need someone writting the
 > personality routine for Ada, that is to say add some stuff in
 > gcc/ada/raise-gcc.c for arm EABI. I might get enough time in the future
 > to try to do so but I've zero experience in this area (both on the Ada
 > side and on the EH side) so even if the patch will likely end up
 > trivial it will take me a long while to figure it out.

I had a look last week at gcc's EH handling. For c++, java, and obj-c
the ARM EABI support looks pretty much the same, and while not small
(much #ifdef code) does look simple enough. The Ada EH code looks
entirely different and frankly I have absolutely no clue where or how
to modify it for ARM EABI.

So right now we have a choice of (a) no Ada for ARM EABI, or (b)
an SJLJ Ada for ARM EABI. With (b) we at least have a working and
testable system until someone can work out the ZCX EH details.

/Mikael

Re: [PATCH][Ada] arm-linux sjlj port

[Richard Earnshaw]

On Mon, 2009-09-07 at 13:14 +0200, Eric Botcazou wrote:
> > Although this patch is completely in the Ada backend, and thus has very
> > little to do with the ARM port maintenance, I'm concerned that we are
> > trying to create an SJLJ port of GCC for ARM linux.  Why is that needed?
> > Why aren't we using the unwind tables?
> 
> GNAT hasn't been ported to DWARF EH for ARM, SJLJ is the only available 
> solution for Ada on ARM as of this writing.
> 

ARM doesn't use the DWARF EH.  IT uses the format specified by the ARM
EABI.

R.

Re: [PATCH][Ada] arm-linux sjlj port

[Richard Earnshaw]

On Mon, 2009-09-07 at 13:31 +0200, Mikael Pettersson wrote:
> So right now we have a choice of (a) no Ada for ARM EABI, or (b)
> an SJLJ Ada for ARM EABI. With (b) we at least have a working and
> testable system until someone can work out the ZCX EH details.

But SJLJ is NOT compatible with the EABI.

R.

Re: [PATCH][Ada] arm-linux sjlj port

[Mikael Pettersson]

Richard Earnshaw writes:
 > 
 > On Mon, 2009-09-07 at 13:31 +0200, Mikael Pettersson wrote:
 > > So right now we have a choice of (a) no Ada for ARM EABI, or (b)
 > > an SJLJ Ada for ARM EABI. With (b) we at least have a working and
 > > testable system until someone can work out the ZCX EH details.
 > 
 > But SJLJ is NOT compatible with the EABI.

Right, it's not if we consider Ada code linked with EH-using
code from other languages or binary code producers that do use
ARM EABI EH. But pure Ada images linked with non-EH using C runtimes
should work. And that's enough for the Ada compiler to sustain
itself (remember that Ada requires Ada at bootstrap-time) while
the limitations are being addressed.

One can build gcc's Ada with ZCX support selected for ARM EABI,
it just needs two small tweaks for compile-time issues. But the
resulting Ada binaries die whenever an exception is raised;
in particular, the Ada compiler itself uses exceptions in a
bootstrap-time helper program (xsinfo, I have a reasonable fix
for that one too). And much of the test suite fails as well.

Would an ARM Ada port with a known broken ZCX EH implementation,
but which is able to rebuild itself, be more acceptable?

Re: [PATCH][Ada] arm-linux sjlj port

[Richard Earnshaw]

On Mon, 2009-09-07 at 15:19 +0200, Mikael Pettersson wrote:
> Richard Earnshaw writes:
>  > 
>  > On Mon, 2009-09-07 at 13:31 +0200, Mikael Pettersson wrote:
>  > > So right now we have a choice of (a) no Ada for ARM EABI, or (b)
>  > > an SJLJ Ada for ARM EABI. With (b) we at least have a working and
>  > > testable system until someone can work out the ZCX EH details.
>  > 
>  > But SJLJ is NOT compatible with the EABI.
> 
> Right, it's not if we consider Ada code linked with EH-using
> code from other languages or binary code producers that do use
> ARM EABI EH. But pure Ada images linked with non-EH using C runtimes
> should work. And that's enough for the Ada compiler to sustain
> itself (remember that Ada requires Ada at bootstrap-time) while
> the limitations are being addressed.
> 
> One can build gcc's Ada with ZCX support selected for ARM EABI,
> it just needs two small tweaks for compile-time issues. But the
> resulting Ada binaries die whenever an exception is raised;
> in particular, the Ada compiler itself uses exceptions in a
> bootstrap-time helper program (xsinfo, I have a reasonable fix
> for that one too). And much of the test suite fails as well.
> 
> Would an ARM Ada port with a known broken ZCX EH implementation,
> but which is able to rebuild itself, be more acceptable?

I don't think either is acceptable.  However, I'm concerned that this
short-term expediency will become a drag to long-term conformance.
Sometimes it's important to get these things right from the beginning or
the legacy will become impossible to eradicate.

R.

Re: [PATCH][Ada] arm-linux sjlj port

[Joel Sherrill]

Laurent GUERBY wrote:
> Hi,
>
> Using Mikael 4.4.1 armel binaries as base compiler:
>
> http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/
>
> And with the following updated patch from Mikael GCC trunk
> bootstraps Ada successfully on arm-linux (sjlj exceptions) 
> and has quite good ACATS results:
>
> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html
>
> Ok to commit to trunk after a complete bootstrap+check?
>
>   
Laurent.. what part of this ARM work do we need for
RTEMS Ada ARM?

> Thanks in advance,
>
> Laurent
>
> 2009-09-07  Mikael Pettersson  <mikpe@it.uu.se>
>
> 	* gcc-interface/Makefile.in: Add arm*-*-linux-gnueabi.
> 	* system-linux-armeb.ads, system-linux-armel.ads: New files.
>
>   

Re: [PATCH][Ada] arm-linux sjlj port

[Laurent GUERBY]

On Mon, 2009-09-07 at 14:27 +0100, Richard Earnshaw wrote:
> However, I'm concerned that this
> short-term expediency will become a drag to long-term conformance.
> Sometimes it's important to get these things right from the beginning or
> the legacy will become impossible to eradicate.

Over the life of GNAT many ports switched from sjlj to zcx (1) and this
had no impact on users including big industrial users with millions LOC
Ada applications. The Ada world tend to be more self contained around
the language standard than the C world :).

Anyway, here is gcc/ada/raise-gcc.c personality:

_Unwind_Reason_Code
PERSONALITY_FUNCTION (version_arg_t version_arg,
                      phases_arg_t phases_arg,
                      _Unwind_Exception_Class uw_exception_class,
                      _Unwind_Exception *uw_exception,
                      _Unwind_Context *uw_context)
{
  /* Fetch the version and phases args with their nominal ABI types for later
     use. This is a noop everywhere except on ia64-vms when called from the
     Condition Handling Facility.  */
  int uw_version = (int) version_arg;
  _Unwind_Action uw_phases = (_Unwind_Action) phases_arg;

  _GNAT_Exception * gnat_exception = (_GNAT_Exception *) uw_exception;

  region_descriptor region;
  action_descriptor action;

  /* Check that we're called from the ABI context we expect, with a major
     possible variation on VMS for IA64.  */
  if (uw_version != 1)
    {
      return _URC_FATAL_PHASE1_ERROR;
    }

  db_indent (DB_INDENT_RESET);
  db_phases (uw_phases);
  db_indent (DB_INDENT_INCREASE);

  /* Get the region description for the context we were provided with. This
     will tell us if there is some lsda, call_site, action and/or ttype data
     for the associated ip.  */
  get_region_description_for (uw_context, &region);
  db_region_for (&region, uw_context);

  /* No LSDA => no handlers or cleanups => we shall unwind further up.  */
  if (! region.lsda)
    return _URC_CONTINUE_UNWIND;

  /* Search the call-site and action-record tables for the action associated
     with this IP.  */
  get_action_description_for (uw_context, uw_exception, &region, &action);
  db_action_for (&action, uw_context);

  /* Whatever the phase, if there is nothing relevant in this frame,
     unwinding should just go on.  */
  if (action.kind == nothing)
    return _URC_CONTINUE_UNWIND;

  /* If we found something in search phase, we should return a code indicating
     what to do next depending on what we found. If we only have cleanups
     around, we shall try to unwind further up to find a handler, otherwise,
     tell we have a handler, which will trigger the second phase.  */
  if (uw_phases & _UA_SEARCH_PHASE)
    {
      if (action.kind == cleanup)
	{
	  Adjust_N_Cleanups_For (gnat_exception, 1);
	  return _URC_CONTINUE_UNWIND;
	}
      else
	{
	  /* Trigger the appropriate notification routines before the second
	     phase starts, which ensures the stack is still intact. */
	  __gnat_notify_handled_exception ();

	  return _URC_HANDLER_FOUND;
	}
    }

  /* We found something in cleanup/handler phase, which might be the handler
     or a cleanup for a handled occurrence, or a cleanup for an unhandled
     occurrence (we are in a FORCED_UNWIND phase in this case). Install the
     context to get there.  */

  /* If we are going to install a cleanup context, decrement the cleanup
     count.  This is required in a FORCED_UNWINDing phase (for an unhandled
     exception), as this is used from the forced unwinding handler in
     Ada.Exceptions.Exception_Propagation to decide whether unwinding should
     proceed further or Unhandled_Exception_Terminate should be called.  */
  if (action.kind == cleanup)
    Adjust_N_Cleanups_For (gnat_exception, -1);

  setup_to_install
    (uw_context, uw_exception, action.landing_pad, action.ttype_filter);

  return _URC_INSTALL_CONTEXT;
}

Looking at libjava/exception.cc the ARM EABI unwinder seems to differ from the other 
platform versions by:

1/ spec of the personality function
2/ return _URC_CONTINUE_UNWIND => replaced by small CONTINUE_UNWINDING macro doing a bit more on ARM
3/ helper get_ttype_entry uses _Unwind_decode_target2 and formulae instead of size_of/read_encoded_value
4/ handle a few more state at the beginning of personality function, this looks like generic boilerplate.

I can try a "no understanding" update of gcc/ada/raise-gcc.c if an
EH/EABI expert tells me there's not much more to do (and understand :).

Thanks in advance,

Laurent

(1) IIRC GNAT was sjlj only for a long time.

Re: [PATCH][Ada] arm-linux sjlj port

[Andrew Haley]

Laurent GUERBY wrote:

> Looking at libjava/exception.cc the ARM EABI unwinder seems to differ from the other 
> platform versions by:
> 
> 1/ spec of the personality function
> 2/ return _URC_CONTINUE_UNWIND => replaced by small CONTINUE_UNWINDING macro doing a bit more on ARM
> 3/ helper get_ttype_entry uses _Unwind_decode_target2 and formulae instead of size_of/read_encoded_value
> 4/ handle a few more state at the beginning of personality function, this looks like generic boilerplate.
> 
> I can try a "no understanding" update of gcc/ada/raise-gcc.c if an
> EH/EABI expert tells me there's not much more to do (and understand :).

There's not much more to do or understand, but it's inevitable
that you'll have to do some debugging.

Andrew.

Re: [PATCH][Ada] arm-linux sjlj port

[Eric Botcazou]

> ARM doesn't use the DWARF EH.  IT uses the format specified by the ARM
> EABI.

Yes, sorry, old habit of automatically translating the GNATism "ZCX".

As Laurent mentioned, many ports of GNAT started as SJLJ ports.  Then the need 
for better performances led to the implementation of ZCX.  The Windows port 
of GNAT is still SJLJ as of this writing, although ZCX is being worked on.

-- 
Eric Botcazou

Re: [PATCH][Ada] arm-linux sjlj port

[Laurent GUERBY]

On Mon, 2009-09-07 at 12:25 +0200, Laurent GUERBY wrote:
> Hi,
> 
> Using Mikael 4.4.1 armel binaries as base compiler:
> 
> http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/
> 
> And with the following updated patch from Mikael GCC trunk
> bootstraps Ada successfully on arm-linux (sjlj exceptions) 
> and has quite good ACATS results:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html
> 
> Ok to commit to trunk after a complete bootstrap+check?

For the record with trunk rev 151524 and the patch testresults:

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00808.html

There is only one ACATS FAIL filed as wrong-code:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41325

And two gnat.dg FAIL, one run time and one spurious warning
probably to be filtered for arm:

raised CONSTRAINT_ERROR : raise_from_pure.adb:5 explicit raise
FAIL: gnat.dg/test_raise_from_pure.adb execution test

FAIL: gnat.dg/warn5.adb (test for excess errors)
Excess errors: warn5.adb:29:30: warning: source alignment (4) <
alignment of "Element_Type" (8)

As discussed I'll try to get ZCX working.

Laurent

Re: [PATCH][Ada] arm-linux sjlj port

[Eric Botcazou]

> For the record with trunk rev 151524 and the patch testresults:
>
> http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00808.html
>
> There is only one ACATS FAIL filed as wrong-code:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41325

Nice.

> And two gnat.dg FAIL, one run time and one spurious warning
> probably to be filtered for arm:
>
> raised CONSTRAINT_ERROR : raise_from_pure.adb:5 explicit raise
> FAIL: gnat.dg/test_raise_from_pure.adb execution test

This one cannot pass with SJLJ for technical reasons, but it's only a missed 
optimization.

> FAIL: gnat.dg/warn5.adb (test for excess errors)
> Excess errors: warn5.adb:29:30: warning: source alignment (4) <
> alignment of "Element_Type" (8)

Yes, ARM is a strict-alignment target, you can add arm*-*-* if you want.

-- 
Eric Botcazou