GCCSDK Development

Introduction

This page lists the current and expected future development activities in the GCCSDK project. This should be useful for all GCCSDK developers and contributors to get an idea of its current status and where we're heading to. We would like to see all discussions on the develoments or any offer to help to be done via the GCCSDK mailing list.

Focus

The current focus is to get GCC 4.1.1 ported (or any later, but marked as stable, version) : first as cross-compiler, secondly to do cross-compilations in the GCCSDK Autobuilder framework (which allows us to test the current cross-compiler with a huge set of code) and thirdly as native RISC OS compiler.

The compiler target, named arm-unknown-riscos, is an own devised ARM ELF flavour which is different from ARM's EABI v2 as we want chunked stack support (in fact implementing the APCS-32 ABI). The compiler will write ELF binaries (RISC OS filetype &e1f) and no longer AIF binaries (an idea to address this for static ELF binaries is to investigate if it isn't possible to convert such static ELF binaries into an AIF binary so that the presence of an ELF loader is not needed, see below).

Support for AOF object files or ALF libraries files is not forseen. This might impose problems when interfacing with 3rd party (especially closed source) libraries. If that really going to be a big issue, it is anticipated that such AOF/ALF support could be implemented as extra code in binutils' BFD library. Note that interfacing with existing AOF/ALF files which are built using Castle C/C++ compiler remains very tricky as the ABI is not 100% the same.

Source

Development is done in the gccsdk repository at 'trunk/gcc4'. The UnixLib developments are done in 'trunk/gcc/unixlib'.

The SVN repository for GCCSDK 4.x only contains patches and copies of new files for the GCC 4.1.1 and binutils 2.17 release. We expect that this way of working will allow us to easily migrate to newer stable versions of GCC and binutils.

During the build we need a copy of UnixLib stored at 'trunk/gcc/unixlib' which is converted from AOF to ELF assembler on the fly. The GCCSDK 3.4.6 at 'trunk/gcc' is temporary needed until GCCSDK 4.x has full module support so that ELF loader as module (at 'trunk/gcc4/riscos/soloader/module2') can be built with GCCSDK 4.x.

Status

• GCC languages: currently C and C++ language are buildable. Fortran is supposed to be buildable too but no build procedure has been added to the README file. Ada (GNAT) is known not be buildable for ARM on GCC 4.1 and its patches for building haven't been added yet. It is unknown what the status is of java, objc and obj-c++.
• GCC testsuite: the GCC testsuite is very easy to run using QEMU running under Linux and helps us in determinating what the current status is of the port. Cfr the current Test results.
• Multilib: currently we have two flavours of our runtime library UnixLib. One using floating point instructions (hardfloat) and the other without (softfloat). The latter has its math operations either inline expanded, either off-loaded to dedicated routines in libgcc.a resuling in impressive speed increases for floating point intensive code. This probably will boil down to making softfloat default and only switch to hardfloat when using the Shared C Library runtime library (and module output). This is not the case yet.
• GCC static ELF output: seems to be very stable. This can be tested for command line programs using QEMU under Linux or natively under RISC OS using Lee Noar's ELF loader.
• GCC shared ELF support (in development) : Necessary patches in GCC ARM backend have been applied. Currently ELF related changes in UnixLib are being made.
• ELF loader : Lee Noar's ELF loader can be used (source code at trunk/gcc4/riscos/soloader) but all the code is written in handcoded ARM assembler. For clarity and to ease future development and support, we would like to have this changed in C code. A start for such C based module has been created at trunk/gcc4/riscos/soloader/module2 (the handcoded ARM assembler version is at trunk/gcc4/riscos/soloader/module) but the main work still needs to be done.
• GCC module support (not started). As soon as we have RISC OS module support (like we have in GCCSDK 3.4.6), there is no need to have the GCCSDK 3.4.6 version at trunk/gcc anymore and we could move trunk/gcc4 to trunk/gcc. At the moment we need module support for developing the C based ELF loader as module. The necessary development steps for module support are:
  • SharedCLibrary support : integrate libscl at trunk/gcc/libscl in the build and make this as runtime library selectable via the -mlibscl option (like we had in GCCSDK 3.4.6)
  • Module support in GCC ARM backend, selectable using -mmodule
  • Enable cmunge from trunk/gcc/riscos-aof/cmunge in our build. Note that cmunge uses gcc preprocessor and its assembler so this will need some update. Also cmunge writes AOF assembler code.
• UnixLib 5.0: the necessary ELF shared library changes are being commited. In the meanwhile all Norcroft/LCC support and legacy GCC support have been removed.
• Static ELF binary to AIF convertor (not started yet) : currently static ELF binaries still need an external ELF loader which might be not ideal in all situations. An idea to address this might be a small program to convert the static ELF binary into a regular AIF binary which would no longer need the external ELF loader.
• Native RISC OS GCC (not started yet) : We might need QEMU running under Linux for the configuration step of GCC.
• GCCSDK Autobuilder work : ELF based porting-scripts have been made (gccsdk/trunk/gcc4/porting-scripts) but changes in some Autobuilder projects are needed (this is work in progress, not everything is commited yet). An important aspect is if, and if so - how long, we will keep the current Autobuilder projects buildable using GCCSDK 3.4.6 (AOF) and GCCSDK 4.x (ELF) at the same time. Because during that period:
  • Required port changes to porting-scripts need to be done for both GCCSDK 3.4.6 and 4.x.
  • Autobuilder projects using AOF assembler (like Desklib, OSLib) can temporary be built using GCCSDK 3.4.6 when instructing its 'as' assembler to output ELF binaries instead. This puts another dependancy on GCCSDK 3.4.6 when building ELF binaries which we would like to see resolved ASAP. For OSLib there are patches available to have an ELF based version but these are not complete nor been commited yet.
• Extra programs: GCCSDK 3.4.6 had a set of various accompagning programs to help the GCC user under RISC OS.
  • Port of bison, diff, fileutils, flex, grep, gzip, make, patch, sed. Most of these are in GCCSDK Autobuilder and if not, they should be added there, together with any useful private RISC OS change made in the port at gccsdk/trunk/gcc/riscos-progs.
  • infozip: this should also be placed in GCCSDK Autobuilder but in GCCSDK 3.4.6 this was also used on the build host to package the final GCCSDK releases and we will need this for GCCSDK 4.x releases as well. The RISC OS filetype support (the -, option) is separately available as patch but not commited yet.
  • resgen (not started yet): small program to create ResourceFS data structures. Need to change this into an ELF version and integrate this in the build. This doesn't make sense to start until we have GCC module support.

Test results

The current gcc/g++ test results for hardfloat configuration are:

                === gcc Summary ===

# of expected passes            37066
# of unexpected failures        40
# of expected failures          77
# of unresolved testcases       32
# of untested testcases         28
# of unsupported tests          332

and

		=== g++ Summary ===

# of expected passes		11934
# of unexpected failures	43
# of unexpected successes	2
# of expected failures		67
# of unresolved testcases	14
# of unsupported tests		114

• An inventory of the outstanding issues needs to be made. Note that some of these problems can be QEMU related.
• There are no softfloat testresults available yet.