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
prev parent 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).