EdgyPlusOneToolchainRoadmap

Revision 11 as of 2006-08-19 04:54:35

Clear message

Summary

This is a high-level overview of the work to be done for the toolchain in the release after Edgy.

We will:

Rationale

The toolchain needs to be ready as of the openning of the release. Because of this, toolchain changes are sketched out at the beginning of the release, finalised near feature freeze, and uploaded to the archive because merges, syncs and uploads start.

Scope

The next release of Ubuntu.

Implementation

  • Update to current upstream versions. As of this writing, we expect these to be:
    • glibc-2.4.x
    • binutils-2.17.x
    • gcc-4.2.x
      • tune with -mtune=generic by default
    • gcj-4.2.x, follow the development of the ecj branch for 1.5 language and runtime features
  • Enable long-double-128 support in glibc and gcc on powerpc and sparc.
  • Perform test rebuild of the edgy archive against these new toolchain releases. we need something like https://launchpad.net/distros/ubuntu/+spec/frequent-rebuild-testing for the rebuilds.

  • Utilize --hash-style=both to get binutils to build binaries that load much faster.

Outstanding issues

  • In support of reducing the number of packages in main and for reducing build time and complexity for security updates, we want to split additional languages into separate packages. At this point, that causes support to be dropped from the main driver, and causes conflicts. We need to investigate if there is a way around this. If not, this issue can be dropped.
  • -mtune=generic is a new feature in gcc which produces better optimised code on Intel chips. We need to confirm that there are no regressions on 32-bit AMD chips before enabling this.
  • We are often asked for using --as-needed by default. We need to provide documentation on why this isn't enabled by default so that it can be made clear. It would also be useful to setup a "Janitors Team" that would go through and check for text relocations or an excessive number of visible symbols in common libraries and would work with upstreams to make tighter DSOs. This group could also expore using --as-needed and linker optimisation as well.
  • I would recommend against -Bdirect only because it creates some excess maintenance (glibc breaks without special attention, for example), and the ABI hasn't been solidified so it may create a useless ELF section that will just take up space in the future. It's sad, but unless this optimization gets major support behind it, Drepper is going to kill it (he refuses to accept it even if it works right); yet at the same time, Meeks is still working on making it 'just work'. --JohnMoser

  • A "Janitor Team" would be nice. Gentoo's security team at [http://hardened.gentoo.org/] is interested in eliminating TEXTRELs; I've [http://revu.tauware.de/details.py?upid=2791 packaged] their [http://www.gentoo.org/proj/en/hardened/pax-utils.xml pax-utils tools], including scanelf which is very good for finding TEXTRELs. I'm sure they would love some assistance. --JohnMoser

  • On the topic of a "Janitor Team," it would be nice to have a similar team but specifically for security purposes. This can be slightly more difficult and time-consuming. Eliminating TEXTRELs has both a performance and security value; but there are also strict security janitor work to be had. The scanelf tool can be used to find libraries that create [http://www.gentoo.org/proj/en/hardened/gnu-stack.xml executable stacks]; fixing these can be trivial, but occasionally requires rewriting code to remove trampolines/nested functions and then fighting with upstream to get the patches included. I've written a couple scripts of my own that find processes with executable stacks and tell you what DSOs cause them as well. --JohnMoser


CategorySpec