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 (note that a small utility, called elf2aif, can be used to convert a static ELF binary into an AIF binary so that the presence of an ELF loader is not needed).

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 is 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 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.

The GCCSDK SCL stub code lives at 'trunk/gcc4/recipe/files/libscl' and UnixLib at 'trunk/gcc4/recipe/files/libunixlib'. GCCSDK related RISC OS programs (like cmunge, ELF loader, elf2aif, etc) are located in subdirectories of 'trunk/gcc4/riscos'.

In the past we used to need GCCSDK3.4.6 at 'trunk/gcc' but this is no longer needed (and does no longer exist either).

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 (hard-float) 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. That's the reason why we made soft-float the default configuration when UnixLib is used as runtime library and use the hard-float configuration when SharedCLibrary is used (including for module code). This in contrast with GCCSDK 3.4.6 which always used hard-float configuration for both UnixLib and SharedCLibrary cases.
• 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. Shared versions of UnixLib and libgcc are now being generated as part of the build process. As a consequence, GCC defaults to dynamic linking which is still a work in progress and does not yet work. We therefore advise anyone using GCC4 to build executables to add the -static flag to their link command line.
• 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 (in development). 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 : a copy libscl from GCCSDK 3.4.6 has been made and stored at gcc4/recipe/files/libscl. It is now part of gccsdk build and this runtime library can be selected using -mlibscl (like in GCCSDK 3.4.6). Doing this will also automatically select hard-float float-abi mode. The libscl stubs.s file is converted to AOF to ELF assemble syntax and currently the only file in libscl.a library. The other C & assembler source files are to be dealt with at a later point in time as those are not important for module support.
  • A copy of CMunge v0.76 is made and stored at gcc4/riscos/cmunge. The necessary ELF changes have been made. AOF output is no longer supported nor available when the -tgcc toolchain is selected.
  • Module support in GCC ARM backend, selectable using -mmodule : option is there and GCCSDK 3.4.6 module backend changes have been ported.

The only remaining and important issue is that the module code still needs to be relocated after it has loaded in RMA. Previously this was done by the __RelocCode but currently we don't have a way to generate the data for __RelocCode or something equivalent. Investigation is ongoing into what our options are.

• 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 : we've written elf2aif, a small program to convert the static ELF binary into a regular AIF binary which would no longer needs an external ELF loader for static ELF binaries. Source code is at trunk/gcc4/riscos/elf2aif.
• 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

On a multicore or multiprocessor system, you can run the testsuites for multiple configurations at the same time using:

make -j2 check-gcc//unix/{-mhard-float,-msoft-float}

The current gcc/g++ testsuite results are:

• hard-float configuration (26 Dec 2006)

                === gcc Summary ===

# of expected passes            37074
# of unexpected failures        33
# of expected failures          77
# of unresolved testcases       32
# of untested testcases         28
# of unsupported tests          332

and:

                === g++ Summary ===

# of expected passes            11958
# of unexpected failures        22
# of unexpected successes       2
# of expected failures          67
# of unresolved testcases       14
# of unsupported tests          114

• soft-float configuration (28 Dec 2006)

                 === gcc Summary ===

# of expected passes            37040
# of unexpected failures        68
# of expected failures          77
# of unresolved testcases       35
# of untested testcases         28
# of unsupported tests          332

and:

                 === g++ Summary ===

# of expected passes            11959
# of unexpected failures        21
# of unexpected successes       2
# of expected failures          67
# of unresolved testcases       16
# of unsupported tests          114

• An inventory of the outstanding issues for the gcc testsuite (and those common for the g++ testsuite):
  • gcc.c-torture/execute/20050121-1.c, gcc.dg/compat/scalar-return-4_y.c: Internal compiler error. Logged as #bug 153.
  • gcc.dg/20021014-1.c, gcc.dg/nest.c, gcc.dg/nested-func-4.c, g++.old-deja/g++.law/profile1.C: Missing mcount() implementation in UnixLib. Logged as #bug 154.
  • gcc.dg/builtin-apply2.c, gcc.dg/builtin-return-1.c, gcc.dg/builtin-apply3.c, gcc.dg/builtin-apply4.c: Missing APCS chunk stack support for __builtin_apply(), __builtin_apply_args() and __builtin_return() ?
  • gcc.dg/trampoline-1: Logged as #bug 155.
  • Incomplete profile support:
    • gcc.dg/tree-prof/inliner-1.c, gcc.dg/tree-prof/val-prof-1.c: undefined reference to __gcov_one_value_profiler() (options -fdump-tree-optimized -fprofile-generate)
    • gcc.dg/tree-prof/val-prof-2.c, gcc.dg/tree-prof/val-prof-3.c, gcc.dg/tree-prof/val-prof-4.c, gcc.dg/tree-prof/val-prof-5.c: undefined reference to __gcov_pow2_profiler and __gcov_interval_profiler.
    • gcc.dg/tree-prof/update-cunroll-2.c, gcc.dg/tree-prof/update-loopch.c, gcc.dg/tree-prof/update-tailcall.c, gcc.misc-tests/bprob-1.c, gcc.misc-tests/bprob-2.c, g++.dg/bprob/g++-bprob-1.C execution: file *.gcda does not exist (using option -fprofile-generate/-fprofile-arcs)
  • PIC issues (might be due that this is not finished yet)
    • gcc.dg/20010912-1.c, gcc.dg/20021018-1.c: -fpic results in crashing binary
    • gcc.dg/20030225-1.c, g++.old-deja/g++.jason/thunk2.C: doesn't link because of missing __rt_load_pic() implementation in UnixLib (-fPIC option)
  • APCS stack issues
    • gcc.dg/20031108-1.c, gcc.dg/arm-mmx-1.c, gcc.target/arm/pr27387.C: warning: -mapcs-stack-check incompatible with -mno-apcs-frame: Testcase problem ?
  • Not yet fully investigated:
    • gcc.dg/asm-fs-1.c: scan-assembler-not \\*_bar
    • gcc.dg/pragma-pack-3.c: runtime assert (invalid pack assumption ?)
    • gcc.dg/sibcall-3.c, gcc.dg/sibcall-4.c: runtime assert
    • gcc.dg/tls/alias-1.c: link error, undefined __aeabi_read_tp
    • gcc.dg/arm-vfp1.c: the main difference in gcc testsuite between hard-float and soft-float comes from the fact that explict specifying soft-float results in an extra set of failures (37 cases) despite the fact that soft-float is default. I.e. "-mfpu=vfp -mfloat-abi=softfp" is ok but "-mfpu=vfp -mfloat-abi=softfp -msoft-float" results in 37 extra failures.

• An inventory of the outstanding issues for the g++ testsuite:
  • Exception handling:
    • g++.dg/eh/forced2.C: runtime crash
    • g++.old-deja/g++.other/eh3.C: runtime abort call
    • g++.dg/expr/anew4.C, g++.old-deja/g++.other/init5.C, g++.old-deja/g++.other/init5.C: runtime abort call (although marked as XFAIL ?!)
  • No support for __attribute__((init_priority(x))):
    • g++.dg/special/conpr-1.C, g++.dg/special/conpr-2.C, g++.dg/special/conpr-3.C, g++.dg/special/conpr-4.C, g++.dg/special/initp1.C: runtime abort because we don't support init_priority attribute of static C++ initialisations. Cfr SUPPORTS_INIT_PRIORITY definition in elf.h. For ARM EABI this patch was posted. Not a big issue.
  • Not yet fully investigated:
    • tmpdir-g++.dg-struct-layout-1/t026: runtime abort
    • g++.dg/warn/huge-val1.C: mathcalls.h:327: error: ISO C++ does not support 'long long' (UnixLib headers not quite right ?)
    • g++.old-deja/g++.abi/arraynew.C: runtime crash (?)
    • g++.old-deja/g++.abi/cxa_vec.C: undefined reference to `__cxa_atexit'