A GNU C library update

Glibc 2.18

The glibc 2.18 release came out in August 2013; David Miller served as the release manager. Some 66 developers contributed to this release, fixing 132 user-visible bugs and three security-related problems with CVE numbers.

This release included a number of new features. There is now priority-inheritance-aware mutex support for condition variables on non-x86 architectures. A new POSIX threads API allows programs to set attributes for all new threads; it can, for example, be used to decrease the default stack size in applications that create large numbers of threads or to allow changing attributes of threads created in libraries. The pt_chown helper program was removed by default in response to CVE-2013-2207; it had so many problems that the developers concluded that they should just get rid of it instead of trying to make it secure. The clock() function now uses clock_gettime(), giving it better precision.

Since it was 2013, Roland said, it was naturally time for 2011 standards to come into effect. So the glibc developers added support for C++11 thread_local destructors in 2.18. There is now support for version 3 of the tzdata file format — something which should become useful sometime around 2038. The worst-case performance of a number of math library functions has been improved.

This release also included a new microbenchmark framework, though testing and benchmarking are still far from where the project would like them to be. The glibc project gets a number of performance-related patches, but it has no real way to judge them to see if they work as advertised and are worth the complexity they might add. The microbenchmark framework will eventually give them an objective way to evaluate these patches. If anybody wants to work with glibc, he said, help in this area would be much appreciated.

Also in 2.18 is a new macro in <math.h> called issignaling(); it can be used to check for sNaN (signaling NaN) behavior as described in ts18661. Support for lock elision using Intel's TSX transactional memory extensions was added, though only part of that patch set went in; see this article for details. Lock elision is still not enabled by default; Roland was unsure whether any distributors were turning it on or not. There is also support for the Power8 architecture and the Xilinx Microblaze processor. The ARM architecture got optimized string routines, and the math library was optimized for the SPARC architecture.

Glibc 2.19

The 2.19 release, under the management of Allan McRae, came out in February 2014. It had contributions from 78 developers and fixed 180 user-visible bugs, six of which were security issues. One of the headline features in this release was much-improved documentation of the thread- and signal-safety properties for each function. The feature test macro system saw the beginning of a long-term cleanup; it was noted that the release notes for the upcoming 2.20 release include a table to guide developers in working with this transition.

2.19 adds support for a number of new locales. There is also better support for binary locale data files; the localdef utility can now cross-compile files for other architectures and (in particular) endianness. A number of new SystemTap probes have been added to malloc() and the math library. 64-bit, little-endian PowerPC support was added as well.

Looking forward

The 2.20 release is to be expected sometime around July or so; it has 28 user-visible bugs fixed so far. In this release, the long-unmaintained am33 port will be removed. There will be improvements to the test suite, including the addition of useful XPASS/XFAIL annotations. The math library will have complete testing for all rounding modes in this release.

The feature test macro transition will continue in 2.20. The _BSD_SOURCE and _SVID_SOURCE macros will be deprecated; developers should use _DEFAULT_SOURCE instead. Keith Packard, from the audience, noted that he was able to remove _BSD_SOURCE from the X library builds with no ill effect. The glibc developers are working toward a goal of having zero build warnings across the library source. The getaddrinfo() function, which has a long history of bugs, is seeing an extensive cleanup at last.

One change that may or may not make it into 2.20 is signal-safe thread-local storage. The current thread-local storage implementation was designed around minimal memory use; to get there, it uses a lazy allocation mechanism that does not actually allocate a thread-local variable until a thread uses that variable. This approach is indeed memory-efficient, but the cost is that allocation must be done while taking locks and doing other things that are not supposed to be done in signal handlers. So signal handlers cannot safely use thread-local storage.

A new implementation almost made it into 2.19, but, in the end, the potential for problems was judged to be too high. So now the plan is to simply preallocate thread-local variables; the lazy allocation mechanism does not really seem to be necessary in most situations. There is agreement on this approach, but nobody has stepped up to actually do the work. Unless that happens in the very near future, this work will not be ready in time for the 2.20 release.

Also possibly coming for 2.20 is the removal of the "ports" directory, which no longer serves its purpose. There are a couple of Google Summer of Code projects in the works; one of those is concerned with better testing for the math library, while the other is focused on an ISO C11 threads implementation. ISO threading is different from POSIX threads, of course; it is hoped that the student working on this project can come up with a useful prototype implementation that can eventually be evolved into something that can be merged into the library.

As Roland ran out of time, he appealed to the audience for help. There is a long list of things needing work. In addition, the developers could use help with bug triage, and, unsurprisingly, documentation. The GNU C Library project has changed a lot in the last few years, and is far more open to changes than it once was. If enough developers respond to that openness, perhaps that "todo" list might just begin to shrink.

[ Your editor would like to thank the Linux Foundation for sponsoring his travel to the Collaboration Summit. ]