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 developments 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 foreseen. 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 determining 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 (soft-float). The latter has its math operations either inline expanded, either off-loaded to dedicated routines in libgcc.a resulting in impressive speed increases for floating point intensive code. This probably will boil down to making soft-float default and only switch to hard-float 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 committed. In the meanwhile all Norcroft/LCC support and legacy GCC support have been removed.
• Static ELF binary to AIF converter (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 : GCC 4.1/ELF specific changes have been committed and are working well. It is expected that almost all future porting work will be ELF-based rather than AOF. The dependency system with the autobuilder makes it straightforward to recompile everything required. Remaining issues are:
  • How long to keep the current Autobuilder projects buildable using both GCCSDK 3.4.6 (AOF) and GCCSDK 4.x (ELF).
  • Autobuilder projects using AOF assembler (like Desklib, OSLib) can temporarily be built using GCCSDK 3.4.6 when instructing its 'as' assembler to output ELF binaries instead. This puts another dependency 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 committed yet. For DeskLib, it is expected that a final AOF-based release will be made, then the sources converted to ELF-format assembler.
• Extra programs: GCCSDK 3.4.6 had a set of various accompanying 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 committed 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 hard-float configuration are:

                === gcc Summary ===

# of expected passes            37068
# of unexpected failures        39
# of expected failures          77
# of unresolved testcases       32
# of untested testcases         28
# of unsupported tests          332

and

		=== g++ Summary ===

# of expected passes		11939
# of unexpected failures	41
# of unexpected successes	2
# of expected failures		67
# of unresolved testcases	14
# of unsupported tests		114

soft-float:

                === gcc Summary ===

# of expected passes            37031
# of unexpected failures        76
# of expected failures          77
# of unresolved testcases       36
# of untested testcases         28
# of unsupported tests          332

and:

                 === g++ Summary ===

# of expected passes            11947
# of unexpected failures        32
# of unexpected successes       2
# of expected failures          67
# of unresolved testcases       17
# of unsupported tests          114

• An inventory of the outstanding issues needs to be made. Note that some of these problems can be QEMU related.