GCCSDK Development

Introduction

This page lists the current and expected development activities for the GCCSDK project. This should be useful for all GCCSDK developers and contributors to get an idea of its current status and road map. Discussions on development or offers of help should be done via the GCCSDK mailing list.

Focus

The current focus is to complete the port of GCC 4.7.4 (and then later versions). The current version is very solid for static binaries as a cross compiler, and all programs in the last few years on riscos.info are built using it. Work on shared library support is complete and considered stable.

The main uses of the compiler are with the GCCSDK Autobuilder framework (which allows testing with a huge set of code) and as a native RISC OS compiler for native development.

The compiler target, named arm-unknown-riscos, is RISC OS-specific 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 creates ELF binaries (RISC OS filetype &e1f) and no longer supports 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 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 Norcroft (Acorn C/C++) compiler remains very tricky as the ABI is not 100% the same.

Quick Start

To quickly build everything:

$ svn co svn://svn.riscos.info/gccsdk/trunk/ gccsdk
$ cd gccsdk/gcc4
$ ./build-world

You will get a message about running for the first time, and editing the file 'gccsdk-params'. Traditionally, we have used a layout under /home/riscos for the final binaries, but this may not always be practical. This is the suggested setup instead:

/home/peter/gccsdk/             - checked out from SVN above
                   gcc4/        - compiler and rest of toolchain
                   autobuilder/ - instructions for automatic package generation
                   cross/       - target for installed compiler and toolchain libraries
                   env/         - target for autobuilt libraries and other cross development tools
                   build/       - work directory for running autobuilder commands (you should create this yourself)

You should edit 'gccsdk-params' to refer to the 'env' and 'build' paths, then run './build-world' again.

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. This should allow us to easily migrate to newer stable versions of GCC and binutils.

The GCCSDK SharedCLibrary 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'.

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 determine the current status. See 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 (considered stable) : Necessary patches in GCC ARM backend have been applied and ELF related changes in UnixLib have been made. Shared versions of UnixLib, libgcc and libstdc++ are generated as part of the build process. In the presence of shared libraries, GCC defaults to dynamic linking; use the -static flag to the link command line to disable dynamic linking.
• ELF loader : Lee Noar's ELF loader can be used (source code at trunk/gcc4/riscos/soloader). The original module written in handcoded ARM assembler has now been rewritten in C at trunk/gcc4/riscos/soloader/module2. The static loader has also been rewritten in C and integrated into the new module as a *command.
• GCC self testing : using the --enable-checking configure option, gcc performs (sometime many) more internal runtime tests. For --enable-checking=all this currently results during the build of gcc itself in:

/home/joty/projects/gccsdk/gccsdk_svn/gcc4/srcdir/gcc/libgcc2.c: In function '__fixunsdfdi':
/home/joty/projects/gccsdk/gccsdk_svn/gcc4/srcdir/gcc/libgcc2.c:1228: internal compiler error: in compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10453

Of course this needs more investigation and further checking the rest of the gcc build.

• GCC module support (in testing stage). Only supported for C code. If we want C++ support as well, this probably needs a multilib pass to have libstdc++-v3 module with -mmodule compiled. We're using this module support for the C based ELF loader as module. The 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 compiled file in libscl.a library (more cleanup work of the libscl sources is needed). 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.
  • In GCCSDK 3.4.6 we had 'resgen' which converted a set of files into an AOF file and also defining a variable pointing to that data allowing (de)registering that data with ResourceFS. As this isn't portable to GCCSDK 4 environment, we got a different approach submitted by Rob Kendrick. His program 'mkresfs' converts the data into a C file together with the (de)registering routines which then needs to be compiled in a second step.
• UnixLib 5.0: the necessary ELF shared library changes have been committed. All Norcroft/LCC support and legacy GCC support has 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. Its use will be mainly to create an AIF binary when -mlibscl is specified at link time.
• Native RISC OS GCC (in testing stage) : it is now possible to build the native RISC OS compiler and use it.
• Not all GCCSDK 3 compiler options added in the RISC OS port are supported in GCCSDK 4. See entries in "Nice to have".
• 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. The trunk version of OSLib has support of both AOF and ELF library building (using GCCSDK 3.4.6 and GCCSDK 4 respectively). For DeskLib, its trunk also has ELF support but in the meanwhile the AOF branch got recently a lot of develoment which is not yet merged to trunk.
• Extra programs: GCCSDK 3.4.6 had a set of various accompanying programs to help the GCC user under RISC OS. Not started yet.
  • 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.

Test results

We are using QEMU with RISC OS support to run the gcc/g++ testsuites (note: other testsuites like binutils one are probably possible but haven't been tried). Those testsuites can be run under different configurations specified by fixed compiler options. Because QEMU with RISC OS support currently only supports static ELF binaries you can only use the static UnixLib as runtime library and this means that for now we always have to specify the '-static' option.

Both hard-float and soft-float UnixLib can be tested efficiently at the same time on a multicore or multiprocessor system as you can run several testsuites under different configurations using:

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

The current gcc/g++ testsuite results are:

• hard-float configuration (29 Oct 2007)

		=== gcc Summary ===

# of expected passes		36871
# of unexpected failures	32
# of expected failures		77
# of unresolved testcases	36
# of untested testcases		28
# of unsupported tests		356

and:

		=== g++ Summary ===

# of expected passes		11781
# of unexpected failures	14
# of unexpected successes	2
# of expected failures		67
# of unresolved testcases	15
# of unsupported tests		146

• soft-float configuration (29 Oct 2007)

		=== gcc Summary ===

# of expected passes		36872
# of unexpected failures	32
# of expected failures		77
# of unresolved testcases	35
# of untested testcases		28
# of unsupported tests		356

and:

		=== g++ Summary ===

# of expected passes		11782
# of unexpected failures	13
# of unexpected successes	2
# of expected failures		67
# of unresolved testcases	15
# of unsupported tests		146

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/cpp/empty-include.c error on empty filename in include: this seems to be an newly introduced error.
• 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-apply3.c, gcc.dg/builtin-apply4.c, gcc.dg/builtin-return-1.c: Missing APCS chunk stack support for __builtin_apply(), __builtin_apply_args() and __builtin_return(). As this is only needed for ObjC and is going to be replaced by libffi in the future, we won't do any effort to fix this.
• APCS stack issues
  • gcc.dg/20031108-1.c: "warning: -mapcs-stack-check incompatible with -mno-apcs-frame" : Testcase problem ?
  • gcc.dg/arm-mmx-1.c, gcc.target/arm/pr27387.C: "warning: -mapcs-stack-check incompatible with -mno-apcs-frame" / "sorry, unimplemented: iWMMXt and hardware floating point": Testcase problem
  • gcc.dg/arm-vfp1.c: "sorry, unimplemented: -mfloat-abi=hard and VFP": 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, IMHO worth further investigation.
  • gcc.dg/trampoline-1.c: timeout, recent problem, IMHO worth further investigation. Logged as #bug 155.
  • gcc.dg/tls/alias-1.c: link error, undefined __aeabi_read_tp, we can probably ignore this one.
  • g++.dg/ext/packed6.C: unexpected compile error "error: cannot bind packed field '((const MAINPACKET*)((u8*)((const MainPacket*)this)->MainPacket::<anonymous>.CriticalPacket::packetdata))->MAINPACKET::header.PACKET_HEADER::setid' to 'const MD5Hash&'", IMHO worth further investigation.
  • g++.dg/parse/pragma3.C: runtime abort, IMHO worth further investigation.
  • g++.dg/warn/huge-val1.C: excess errors, mathcalls.h:327: error: ISO C++ does not support 'long long' (UnixLib headers not quite right ?)
  • g++.old-deja/g++.abi/cxa_vec.C: runtime crash in __cxa_vec_ctor(), IMHO worth further investigation.
• 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: file *.gcda does not exist (using option -fprofile-generate/-fprofile-arcs)

Developer help wanted

In case you are a developer and want to spend some time on the GCCSDK project, this is a non-exhaustive list of ideas to get you inspired:

On the agenda

Things which more or less need to be done before a release.

• SharedCLibrary stub code: currently only the very minimal stub code is in libscl.a and the remaining C and assembler code from GCCSDK 3 is not used. This needs to be cleaned up and evaluated what bits we want to keep or extend.
• Help testing it. Run the testsuite, verify there are no new failures or cross-compile your own programs and see if it works like expected.
• Investigate the remaining uninvestigated testsuite failures to see if there are any important issues left to be dealt with.
• GCCSDK 3 had patches for its infozip program to support filetype support via ",xxx" filename extension. We will need an updated infozip program with these patches to package RISC OS GCC distribution. Talk to John Tytgat.

Nice to have

• We're focusing on getting C and C++ fully supported. Extra pair of hands could investigate what the status is of Fortran, Ada, Java, ObjC and Obj-C++ and maybe have it supported too with a (hopefully small) extra effort.
• Profile support. It is very worthwhile for developers to have profile support but we don't have it nor it is 100% clear which bits are missing.
• AOF support : although we don't have it on the wanted feature list we can already anticipate requests for it. E.g. for the TCPIPLib support for module code. It would be a nice project on its own to support AOF/ALF object format in BFD library which is part of binutils. The linker using the BFD library would then have AOF/ALF support and probably also interlinking support between AOF/ALF and ELF. There are already known catches like a different 'weak' semantic between AOF and ELF and also Norcroft APCS-32 calling convention for floats is different. But nevertheless could be useful to have.
• GCCSDK 3 options which are not in GCCSDK 4:
  • Option -mamu : Generate the file !Depend which contains a list of all the source files that the produced object depends on. This is intended for use with Acorn's Make Utility (AMU), which edits the makefile to include these after the '# Dynamic Dependencies' line.
  • Option -mlibrary-static-data-offset, -mclient-static-data-offset: only used in a very specific case for creating a SharedCLibrary clone.
• The transparent filename translation in UnixLib is powerful but unfortunately sometimes very difficult to get it right.
  • We could make use of a testqueue in order to see if additional changes do not break the current behaviour in an unwanted way. We already have something (see recipe/files/libunixlib/test) but it needs further enhancement.
  • When command line based programs are ported, they can usually only be used using Unix style of filenames as parameters which is from porter's POV the easiest option (and thanks to UnixLib transparent translation this usually works out of the box) but from user's POV very unfriendly. An interesting approach to address this is done by Duncan Moore who developed libDM which he used in several known command line ports. He doesn't have time to persue this further but the idea is appealing to include it or something very similar in UnixLib and support those calls in the command line based autobuild projects.
• We're now outputing DWARF2 debug information but we don't have an ELF debugger. The obvious candidate is to make use of The GNU Project Debugger (gdb). There are two possible approaches:
  • Either use gdb as remote debugger and create a remote protocol stub for RISC OS which loads and controls the ELF RISC OS binary and communicates with gdb running an the remote host. This is probably the most easiest thing to do but not suited for developers who only have a RISC OS box to develop on.
  • Either port gdb natively to RISC OS. This hasn't been investigated if this is reasonably possible but it is probably very tricky to get it working.

Discussions, questions, new development ideas or just a statement you're want to help here can be done in GCCSDK mailing list.

Links

• The GNU configure and build system (texi format) : this is also available as etc/configure.info inside any official binutils distribution. An older version of this document can be found here as HTML.

GCC and GCCSDK pages

GCC under RISC OS GCC for RISC OS, GCC tutorial, GCC common switches, GCC for beginners, UnixLib, ELFLoader GCCSDK and Unix porting GCCSDK, GCCSDK Releases, GCCSDK Development, Using GCCSDK, Autobuilder Development and Packaging Cygwin setup, Accelerating autobuilder with apt-proxy, ChoX11, Developer help wanted