From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8369 invoked by alias); 2 May 2002 16:07:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8346 invoked from network); 2 May 2002 16:07:19 -0000 Received: from unknown (HELO mail.oarcorp.com) (216.107.91.228) by sources.redhat.com with SMTP; 2 May 2002 16:07:19 -0000 Received: (qmail 24523 invoked from network); 2 May 2002 16:07:18 -0000 Received: from unknown (HELO OARcorp.com) (192.168.1.2) by 0 with SMTP; 2 May 2002 16:07:18 -0000 Message-ID: <3CD162F3.9E406777@OARcorp.com> Date: Thu, 02 May 2002 09:07:00 -0000 From: Joel Sherrill Reply-To: joel.sherrill@OARcorp.com Organization: OAR Corporation X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: updated gcc 3.1 cross ada report Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00155.txt.bz2 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 #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 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