A GNU C Library update

Recent history

The glibc 2.20 release came out last August featuring contributions from 69 developers. This release fixed 160 bugs, four of which had CVE numbers attached to them. It added support for Intel's MPX memory protection mechanism to the dynamic loader; that support is not useful for much now, but it will be a useful preparation once MPX-enabled applications appear in the future. Lock elision support has been added for the s390 architecture. There are new, optimized string functions for the ARMv7 and ARM64 subarchitectures, while support for the ancient AM33 subarchitecture has been removed.

Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have been removed. The declarations formerly available under those macros are now under _DEFAULT_SOURCE, but, since it's the default, one need not set it explicitly. Roland's suggestion, though, was that most code would (continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros. (See this article for an introduction to glibc feature test macros).

Support for file-private POSIX locks has been added to this release. And, finally, as of 2.20, the oldest supported kernel release is 2.6.32. Users staying with older kernels are, most likely, not going to update their C library either.

Glibc 2.21 was released on February 6. It had changes from 61 developers, fixing 101 bugs and five security issues. The MIPS architecture has gained support for the O32 FPXX, FP64, and FP64A ABIs. Support for the obsolete sigvec() functions has been removed (though ABI support remains for older binaries). The sigvec() ABI dates back to the 4.2 BSD release and, Roland said, was replaced by sigaction() 25 years ago.

The 2.21 release includes support for a handful of new locales. The i386 memcpy() implementation has been optimized. The PowerPC architecture has gained support for lock elision and optimized string functions as well. Various architecture-specific semaphore implementations have been replaced by a single generic version written in C; that should help the developers to maintain this code and avoid introducing race conditions in the future. Also in this release is support for Altera's NIOS II architecture.

The 2.22 release cycle has just gotten underway; as of Roland's talk it had five bugfixes but not much else. He expects to see a rework of the POSIX thread cancellation code to fix some race conditions there. The process of cleaning up the atomic-operation and futex code will continue as well; it is part of a long-term project to move the library toward the C11 memory model. Once that is done, he said, the developers should be able to have a higher level of confidence in the correctness of the library's synchronization code.

Glibc in the next five years

Looking forward, Roland said that, five years from now, the glibc developers will have put out ten releases and, probably, have fixed about 1,500 bugs. But it would be nice if the project could accelerate a bit, bringing in more useful features while maintaining the quality of the code. To do that, though, the developers need some more help.

One place where interested people could contribute is in bug triage. It takes a lot of work to go through the bug tracker, assign priorities to bugs, determine whether they might have security relevance, create minimal programs to reproduce bugs, and, even, write patches to fix them. Another area where help is needed is with benchmarks; what is there now is not really adequate to judge the value of performance patches. Benchmarks for the math library are especially needed. Microbenchmarks are valuable, but there is also a need for whole-system benchmarks that can be used for workload-specific tuning. Writing benchmarks, Roland said, is a great way to develop a working knowledge of the API.

Then, there is the matter of testing infrastructure. Glibc is, by its nature, a conservative project that puts a premium on not breaking things. Often the biggest blocker for new patches is the simple lack of adequate testing; a good automated testing framework would help the project to merge new code more quickly. The problem is not an easy one, though, he said.

Among other things, the project needs test suites that can run against an installed version of the library. Otherwise it can be hard to test the resolver and other parts of the library that interact with the rest of the system and the network. Some of the more complex tests probably need to be run within containers. Also needed is ABI comparison testing; the project has some "superficial" tests now that look at symbols, versions, and the size of data objects, but there's no testing for ABI breakage beyond that. The libabigail library out of the GCC project should probably be brought in to help with this task.

Finally, the developers could use help supporting the project's infrastructure — the wiki, bug tracker, build systems, etc. Interested people should consult the project's master "todo" list for lots more information.

An audience member asked about the handling of security bugs. Roland answered that the project Bugzilla includes a flag to mark whether any particular bug has been reviewed for security implications. The project could use some help with that kind of review, he said. One of the recent CVE entries for glibc referred to a bug that had been fixed in 2013, but nobody had realized at the time that it was exploitable. It would be nice to catch more of those, but, Roland said, the primary responsibility for identifying and responding to security bugs lies downstream with the distributors.

Another attendee asked about EGLIBC. Roland said that he's not really the right person to talk about that project but that, as far as he can tell, it has mostly gone away. Some of the developers behind the EGLIBC fork are now core glibc developers, and most (but not all) of the EGLIBC changes have been pulled back into glibc. In general, Roland would like to see all of the glibc forks out there merge back into the mainline. But, while distributors have patches that they apply, he is not aware of any distributors shipping forks at this point.

The next question had to do with contributor-agreement process that developers must go through to get code accepted; it was described as being complicated and an obstacle to contribution. Roland agreed with that assessment, but said that the legal aspects were outside of the project's control. Glibc is a GNU project; that fact is not going to change. It would be nice if the agreement process could be streamlined, but it is up to the GNU project to do that.

The last question had to do with support for building the library with the LLVM compiler. It was noted that there has been pushback against the merging of LLVM support into some GNU projects; would there be difficulties in getting LLVM support into glibc? Roland answered that he didn't see any reason for there to be trouble. In general, the glibc developers have been working toward the use of more standard language features and getting away from GCC extensions. That is a technical goal aimed at making the glibc code better. Technical improvement is where the glibc project's interests lie; the glibc developers, he said, are uninterested in the political issues.

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

    #define MY_CREATE O_CREAT