This is the mail archive of the
mailing list for the GCC project.
updated gcc 3.1 cross ada report
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 02 May 2002 11:01:55 -0500
- Subject: updated gcc 3.1 cross ada report
- Organization: OAR Corporation
- Reply-to: joel dot sherrill at OARcorp dot com
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:
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
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
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
The targets that fail like that are:
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