updated gcc 3.1 cross ada report

updated gcc 3.1 cross ada report

[Joel Sherrill]

Hi again,

I have gotten far enough on testing cross gnat 3.1 based *-rtems
targets to give a report.  This report is based upon a few RTEMS
specific patches, one general single line gnat cross one, and
some hand-hacking on generated Makefiles for two targets.  I
think the patches are OK for 3.1 if Mark thinks so too.

First the good news, I have successfully built and installed
Ada compilers for the following targets:

arm-rtems
i386-rtems
mips-rtems
powerpc-rtems
sparc-rtems

And now the really good news... ACATS results on SPARC/ERC32:

acats4gnat results cz 3 /       4
acats4gnat results a 75 /      75
acats4gnat results c2 35 /      35
acats4gnat results c3 344 /     349
acats4gnat results c4 335 /     338
acats4gnat results c5 95 /      95
acats4gnat results c6 81 /      81
acats4gnat results c7 50 /      50
acats4gnat results c8 140 /     140
acats4gnat results c9 250 /     255
acats4gnat results ca 74 /      74
acats4gnat results cb 43 /      43
acats4gnat results cc 117 /     117
acats4gnat results cd 172 /     172
acats4gnat results ce 262 /     268
acats4gnat results cxa 69 /      85
acats4gnat results cxb 30 /      30
acats4gnat results cxc 10 /      16
acats4gnat results cxd 30 /      39
acats4gnat results cxe 1 /       1
acats4gnat results cxf 20 /      20
acats4gnat results cxg 20 /      29
acats4gnat results cxh 4 /       4
acats4gnat results d 4 /       4
acats4gnat results e 11 /      11
acats4gnat results l 26 /      26


They look pretty good for a first run.  How does this
compare to GNU/Linux or Solaris?

==================================================
The arm-rtems required adding this to adaint.h

#if defined(__rtems__)
#include <stdio.h>
#endif

I have not used it yet to try to compile RTEMS.
==================================================
The mips-rtems required hand-editting the ada/Makefile to fix
a path to ecoff.h defined by CONFIG2_H that ended up relative
to gcc/ada/ instead of gcc/.

Some CPU arguments changed and I can't build the RTEMS
BSP I want to test with so this is OK as best I can tell.
==================================================
The powerpc-rtems target built and installed OK.
I have a linking problem with RTEMS that is powerpc-rtems
specific I am trying to resolve.  We have to have
a stub to provide all symbols when configure 
links the dummy main but for some reason
__CTOR_END__, __CTOR_LIST__, and their dtor versions
are coming up undefined.  Suggestions on how to
hack these into either the default linker scripts
or RTEMS dummy crt0.c are appreciated.  So far,
I can't find the magic combination to make the
linker happy.  The resulting executable is known
to be bogus -- this is just to make autoconf happy.
==================================================
The i386-rtems has compiled RTEMS but also has
a BSP specific link issue with Ada programs that
is new to the 3.1/binutils 2.12 combination.
==================================================
With Jim Wilson's i960/ada patch that target builds
until it fails because it does not support
Ada exceptions.
===================================================

That leaves the build failures.  Most fail with this:

raise.c: In function `__gnat_eh_personality':
raise.c:601: built-in function `__builtin_eh_return_data_regno' not
currently supported

The targets that fail like that are:
        h8300-rtems
        i960-rtems
        m68k-rtems
        sh-rtemself
        sh-rtems

These targets look like a place for a volunteer to do some
work. This is not an RTEMS specific failure but indicates that
the CPU port does not support Ada. 

hppa1.1-rtems is unique and fails when NAME_MAX is not defined in
<sys/dirent.h> included from adaint.h.  I think this is essentially
the arm problem in another guise.

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