public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: "Ralf Corsepius" <ralf.corsepius@rtems.org>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"Thomas Dörfler" <Thomas.Doerfler@embedded-brains.de>
Subject: Re: [PATCH, ARM] Switch to EABI version 5 for RTEMS
Date: Wed, 13 Apr 2011 18:25:00 -0000	[thread overview]
Message-ID: <4DA5EA90.5040509@oarcorp.com> (raw)
In-Reply-To: <4DA560EF.10505@embedded-brains.de>

On 04/13/2011 03:38 AM, Sebastian Huber wrote:
> On 04/06/2011 07:20 PM, Sebastian Huber wrote:
>> On 06/04/11 18:24, Ralf Corsepius wrote:
>>> On 04/06/2011 05:20 PM, Sebastian Huber wrote:
>>>
>>>> there were several requests for ARM Cortex-M support on RTEMS
>>>> recently.  The
>>>> first step towards this is a suitable ARM tool chain.  I want to use
>>>> this event
>>>> to clean up the multilibs and switch to the EABI version 5.  The
>>>> benefit of
>>>> EABI version 5 is that this brings RTEMS more in line with the
>>>> primary GCC
>>>> platform arm-linux-gnueabi.
>>> These patches are not OK with me, because these are widely
>>> incompatible to what has been used in RTEMS up today
>> Can you please list these incompatibilities.  The RTEMS test suite shows
>> no problems with this tool chain.  The GCC test suite looks also good.
> [...]
>
> It is not really helpful to claim something without an explanation.  The
> missing tool chain for the ARM Cortex architecture blocks RTEMS from further
> development on a very important embedded systems platform.  A lot of competing
> real time operating systems provide ARM Cortex support for a long time.
>
> Lets look at the GCC test suite results:
>
Wow!  The improvement is fantastic.

These would impact only new release branches of RTEMS and
we are months away from a new release branch.  If something
breaks, now if the time to find it out.

> RTEMS 4.11, GCC 4.6.0 (EABI)
>
> 		=== gcc Summary ===
>
> # of expected passes		72429
> # of unexpected failures	200
> # of unexpected successes	7
> # of expected failures		183
> # of unresolved testcases	138
> # of unsupported tests		1103
>
> 		=== g++ Summary ===
>
> # of expected passes		25494
> # of unexpected failures	11
> # of unexpected successes	1
> # of expected failures		160
> # of unsupported tests		427
>
> RTEMS 4.11, GCC 4.6.0 (old ABI)
>
> 		=== gcc Summary ===
>
> # of expected passes		43613
> # of unexpected failures	15916
> # of unexpected successes	8
> # of expected failures		181
> # of unresolved testcases	11127
> # of unsupported tests		1124
>
> 		=== g++ Summary ===
>
> # of expected passes		20709
> # of unexpected failures	2590
> # of expected failures		157
> # of unresolved testcases	291
> # of unsupported tests		430
>
> RTEMS 4.10, GCC 4.4.5 (old ABI)
>
> 		=== gcc Summary ===
>
> # of expected passes		34293
> # of unexpected failures	11273
> # of expected failures		237
> # of unresolved testcases	7878
> # of unsupported tests		683
>
> 		=== g++ Summary ===
>
> # of expected passes		15707
> # of unexpected failures	1726
> # of expected failures		155
> # of unresolved testcases	26
> # of unsupported tests		194
>
> RTEMS 4.9, GCC 4.3.2 (old ABI)
>
> 		=== gcc Summary ===
>
> # of expected passes		47164
> # of unexpected failures	2070
> # of expected failures		97
> # of unresolved testcases	92
> # of untested testcases		35
> # of unsupported tests		792
>
> 		=== g++ Summary ===
>
> # of expected passes		17019
> # of unexpected failures	52
> # of unexpected successes	2
> # of expected failures		82
> # of unresolved testcases	49
> # of unsupported tests		164
>
> The EABI tool chain has by far the best test suite results.
>
> The RTEMS test suite was run with the edb7312 BSP and shows good results.  It
> works also on real hardware with the lpc24xx and lpc32xx BSPs.
>
> All ARM BSPs compile and link all tests with the EABI tool chain.
>
> We use the VFP floating point format in all ARM BSPs since 2010-04-30.
>
> All ARM BSPs support the init and fini array sections since 2010-12-03.
>
> The C++ exceptions change from SJLJ to a table based implementation is an
> implementation detail.
>
> The required ARM/Thumb interwork is an enhancement.
>
> I don't claim that the switch to the EABI tool chain will be without problems,
> but we have to use it to figure this out.  The multilib selection may need
> further changes.  I am concerned about the enabled exceptions in some libgcc
> functions.
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985


      reply	other threads:[~2011-04-13 18:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06 15:20 Sebastian Huber
2011-04-06 16:25 ` Ralf Corsepius
2011-04-06 17:16   ` Sebastian Huber
2011-04-13  8:38     ` Sebastian Huber
2011-04-13 18:25       ` Joel Sherrill [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DA5EA90.5040509@oarcorp.com \
    --to=joel.sherrill@oarcorp.com \
    --cc=Thomas.Doerfler@embedded-brains.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ralf.corsepius@rtems.org \
    --cc=sebastian.huber@embedded-brains.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).