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.sherr...@oarcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


Reply via email to