GCCSDK Development

From RISC OS
Revision as of 02:01, 15 July 2007 by Joty (talk | contribs) (Noted that we've made a first step for building the native RISC OS compiler.)
Jump to navigationJump to search

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 and ELF related changes in UnixLib have been made. Shared versions of UnixLib, libgcc and libstdc++ are now being generated as part of the build process. As a consequence, GCC defaults to dynamic linking which does work, but a method of gathering the required parts together automatically in a form that can be transferred to RISC OS has yet to be developed (although it can of course be done manually). We therefore advise anyone using GCC4 to build executables to add the -static flag to their link command line unless they specifically wish to experiment with 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 module support (working but needs finishing touches). 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. Note we're going to use this module support for developing 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 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.
    • Currently an explicit 'objcopy -binary' operation still needs to be done after linking in order to convert the module-in-ELF-jacket into a real RISC OS module with filetype &ffa. This should be done transparently by collect2 when the intenal option --ro-module-reloc is given to the linker (to be done).
    • 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 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 (in development) : it is now possible to build the native RISC OS compiler. It is not fully working on RISC OS yet.
  • 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. ELF version of OSLib has been commited but is not yet on the 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

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(). 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.
    • 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'

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.

  • Native GCCSDK 4 RISC OS build.
  • Help with shared ELF support (including the ELF loader as C based module). Talk to Lee Noar.
  • Help with the remaining module support (especially getting rid of the extra "objcopy -binary"). Talk to John Tytgat.
  • 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.
  • 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

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

Retrieved from "http://www.riscos.info/index.php?title=GCCSDK_Development&oldid=3487"