This year the GNU Tools Cauldron was hosted by Google at their California headquarters and the Embecosm team were there in strength. While a cauldron typically implies heat, this was in many ways very much a cool place to be: the talks were leading edge, the venue had great facilities, and the temperature was much more pleasant than back in the UK.
I’m not going to go through the entire program here — you can find the slides and links to videos on the meeting website — but I’ll pick out a few items which caught my imagination.
Talks at GNU meetings come in three flavours:
- “birds of a feather” (BoF) sessions are where specialists in one area go into immense detail on their area of interest ;
- porting talks allow engineers to share their experience of getting one or more GNU tools up and running on a new architecture; and
- R&D talks explore the bleeding edge of tool development.
BoF sessions
BoF sessions tend to be seriously in-depth, and unless you are into that particular speciality and track it very closely you have little chance of understanding what the participants are discussing.
This year I found a BoF that I did understand and in which I could participate. The original developer of the DejaGnu test framework, Rob Savoye, ran a session on his plans to rewrite DejaGnu in Python, as part of his work for Linaro. The motivation for change is partly to improve the system by making it less general purpose, and to move to a newer, actively maintained language. DejaGnu was originally conceived as a library that other products could incorporate, but it has only ever been used as a testing framework, mostly, but not exclusively, for GNU tools. It is written in expect, which in turn is an extension of Tcl, which is then used for scripting.
Personally, as a heavy user of DejaGnu for tool chain testing, its most frustrating aspect is the use of Tcl for scripting. While Tcl was a great innovation when it originally came out, its ambiguity when it comes to escaping can be frustrating, and particularly when trying to write regular expressions for pattern matching, which is a core activity in test scripts. I wasn’t the only one who thought this a problem and we had a lively and constructive discussion over the most appropriate language and the best way to describe pattern matching.
A strong case was made for using the GDB mi descriptions, with equally strong arguments being made against tying into such a specific interface. If you have a view, particularly on the best way to describe pattern matching — SNOBOL4 anyone? — now is the time to share them via the DejaGnu mailing list.
Talks on porting
Porting GNU tools is a large part of Embecosm’s business and talks on porting are always a good opportunity to share experiences. The talks on GDB for the TI C6xxx series and GCC for PowerPC were both informative, but for me the best was Richard Earnshaw and Ramana Radhakrishnan talking about the ARM AArch64 port. The reason was not that ARM’s 64-bit architecture is exciting (which it is), but their description of newlib-nano.
Newlib-nano is a re-engineering of their newlib implementation to reduce the size of the library that is linked. In particular printf can easily pull in half the library, with dependencies on all the I/O and memory allocation routines, almost invariably unnecessarily. The good news is that most of the changes are incorporated in mainline newlib, so any new port can take advantage of their changes.
R&D talks
Embecosm presented as part of the R&D talks. James Pallister described his work on measuring the impact of compiler options on energy consumption in compiled code, while Simon Cook and I gave an introduction to the MAGEEC project, which is laying the groundwork for the next generation of machine learning-enabled compilers. James has already published a number of posts here on his work on measuring energy consumption, and Simon and I will be posting in the future about work with MAGEEC.
Of the other R&D talks I was particularly impressed by David Malcolm of Red Hat talking on removing state from GCC. One of the effects of LLVM’s rise to prominence has been to spur development in GCC, and in particular the long overdue move to C++. In many respects GCC is already object-oriented, but its inception pre-dated the emergence of C++ as a mainstream language. Consequently the GCC code base is littered by a vast library of macros, which add OO functionality to standard C. These represent a huge learning barrier to new participants, and are by-and-large impossible for source code debuggers to handle.
David is focusing on providing only one part of the C++ transition: the elimination of global variables. However, there are 3,500 such variables used in 100,000 places, so this is no small task! While some will be moved into global singletons (arguably keeping many of the limitations of global variables) most will be moved to become member variables of the classes with which they are associated — whether the pass manager in the back end, individual passes, or other parts of the system. A very laudable project, and one which was enthusiastically supported by the audience—perhaps to the alarm of David Malcolm, who is only too well aware of the scale of the challenge.
The future of GNU tools
In general GNU tools meetings are cheerful and friendly events, but there is always the excitement of grilling the steering committee on the final morning. This year, there was a strong theme of frustration with the FSF administration, with too many stories of delayed and lost paperwork for approval to commit. Which is something the committee can lobby hard about, but for which they are not directly responsible.
From my experience, the people at the FSF work hard, but don’t always have the most effective software systems supporting them. Which is perhaps a consequence of an absolute commitment to free software, but means that in some areas they may be relying on projects that have not yet reached maturity. The solution which others have recommended, and that I myself have used in the past, is to get on the telephone and bypass the aforementioned technology!
There was strong support for a GNU Cauldron next year and we can expect it to be held in Europe or Asia.
