Toolchain Working Group Flyer

r2d June 2012

This page introduces the Toolchain Working Group, how we work, and what you can expect from us from a consumer point of view.


The group's goal is to improve the competitiveness of Cortex-A series devices, especially the Cortex-A9 with NEON and SMP. We emphasise performance and are neutral on correctness. Most of the performance effort is on improving compilers and libraries, and some is on providing good developer tools to allow the developer to track down the remaining issues and get the device to market.

The primary platforms are Linux on Cortex-A, i686, and x86_64. Improvements are done for the Cortex-A. The other primary platforms are built, tested, and supported by the group. This gives us a wider range of tests, makes changes more likely to be accepted upstream, and makes the toolchain more useful for multi-platform products such as Ubuntu.

While we do focus on the Cortex-A, we attempt to 'do no harm' to other architectures. The performance and correctness should be no worse than the corresponding upstream version. We plan to monitor the correctness, speed, and size of the automated builds in the following combinations:

  • ARMv7 + Thumb2 + NEON, tuned for Cortex-A9
  • ARMv7 + Thumb2 + VFP
  • ARMv5 + ARM + Software FP
  • ARMv5 + Thumb1 + Softare FP
  • i686
  • x86_64

Correctness regressions will be fixed. Significant size or performance regressions will be fixed.


We run a short monthly consolidation cycle and a longer six month planning cycle. The consolidation cycle focuses on making any group outputs available in an timely, tested fashion. A consolidation cycle consists of three weeks of development and one week for the release process. Releases are made on the second Tuesday of each month.

Work is generally done upstream first and then backported to the consolidation branch. Work that is done in Linaro first is done in a topic branch, tested and accepted there, and then merged into the trunk in one step. The trunk should be generally stable but is only guaranteed to be good at every consolidation release.

Extra effort is made at the end of a planning cycle to combine the outputs from the different Linaro working groups into a coherent set.

The features of an output should not regress from release to release. A consumer should be able to start on one release of a series and easily update to a later release without losing functionality. Talk to us if you need this type of support.


The group is currently focused on the core toolchain including GCC, GDB, binutils, GLIBC, and QEMU. The current primary outputs are:

These are maintained and activly developed by the group. Management is done via including planning, issue tracking, source code control, and releases.

Sometimes we do one-off work to improve ARM support in a product. If the changes warrant it, we will make snapshots of the project that are as correct as the last upstream release but provides better ARM support. These secondary releases are designed to be superseded by upstream and are generally managed using upstream's tools. Current secondary outputs include:

  • ltrace
  • libunwind
  • libffi

Release are done both as tarballs and as tags in version control. The tarballs are built using the same process as the upstream version and should be drop-in replacements for an upstream release.

Check the Toolchain Working Group home page at for links to the releases and branches.


We support both a GCC 4.6 based maintenance series and a GCC 4.7 based development series. These are based on the corresponding FSF release branches and are updated to the latest upstream revision once a month.

Updating to the latest revision helps to exercise the upstream changes and reduces the chance of an upstream bug surviving through to the release. The risk of picking up other issues is low due to upstream's release branch policy.


Linaro works in the open. The Toolchain WG communicates via:

  • The #linaro IRC channel on / Freenode
  • The email list (subscribe)

  • Weekly meetings via conference call
  • Weekly stand up meetings also via conference call
  • for all issues and planning

The minutes, as well as a recording of the call, are published shortly after each meeting. Anyone is welcome to dial in and join in the call.

Planning is done via the Launchpad blueprint system. A list of the high level topics under consideration can be seen via the Linaro blueprints page at:

Bugs are tracked through the Launchpad bug tracker at:

You can also ask questions on Ask Linaro:

Commercial support is under consideration. Please inquire at


The outputs are tested by plan and testing through use. Testing by plan involves running the output's test suite and preferably also using the output in other stages.

For example, on GCC this involves:

  • Running the GCC testsuite for all languages
  • Running the libstdc++ testsuite
  • Building EGLIBC with the new compiler and running the testsuite
  • Building Python with the new compiler and running the testsuite
  • Building a selection of essential packages from Ubuntu
  • Building and running a range of benchmarks

Any failures are analysed and compared against upstream. Those that fail in the output but not in upstream are regressions and are triaged. Performance regressions are acceptable in the short term. Correctness regressions should be fixed before any release.

As part of fixing a bug, a regression test is created and added to the GCC testsuite.

Testing through use involves using the output in real, large projects such as distributions like Ubuntu. For Linaro GCC this involves using the compiler to build the ~2,000 packages in Ubuntu and running the package test suites in as many as practical. This shakes out many of the compiler issues before most consumers see them. Any issues found are traced as bugs in and often lead to a regression test.

The current checked-in version of all outputs is continuously built and tested on Thumb-2, i686, and x86_64. Results are published in an easy-to-find manor.


An output goes through the following lifecycle:

  • Investigation
  • Development: fixes and improvements are made
  • Maintenance: important fixes are made
  • Retired: output is still available but no longer supported

For GCC, we support a current series which is under development and a previous series which is under development or maintenance. The previous series goes into retirement when a new series is released.

For example, say we currently have a 4.4 and 4.5 series and are investigating a 4.6. 4.4 is in maintenance and 4.5 is in development. When 4.6 is released, 4.4 is retired and 4.5 goes into maintenance.

All outputs should eventually be superseded by upstream. This gives the consumer other options should they wish to stay on a particular version for the long term.


Consumer-reported bugs are addressed promptly. As part of being neutral on correctness, we don't activly try to find bugs but do address them quickly as they are found.

A typical support model splits the load between the group and the consumer. Assuming the problem was found in a package, the consumer should:

  • Triage the problem and see if it is a package or toolchain issue
  • See if it is already reported in the package upstream
  • If practical, treat the problem as an application problem and track it down further
  • If practical, supply a reduced test case

The toolchain group would:

  • Respond promptly
  • Investigate and fix the problem
  • Make a patch available through version control
  • Get the fix accepted upstream
  • Make the fix available in the next monthly release

Any fixes are be made to the latest version of the series only. We do not intent to backport fixes to earlier releases in the same series.

For example, say a consumer picks up Linaro GCC 4.5-2011.03. Three months later, the consumer finds a problem. The fix will be released in the next monthly Linaro GCC release, which will probably be Linaro GCC 4.5-2011.07.


In the future, the group would like to expand into the following areas:

  • Other toolchain components, such as LLVM, OpenCL, and other ways of improving the competitiveness of ARM processors
  • Supplying binary builds with every consolidation cycle so that people can more easily use our outputs
  • Widening the binary builds to include non-core components, and other distributions including Fedora, openSUSE, and Windows
  • Widen the testing by plan to test more with each build

WorkingGroups/ToolChain/Flyer (last modified 2012-06-06 23:10:24)