One of the developers from Google the topic of developing a cross-platform standard C library (Libc) within the LLVM project on the LLVM mailing list. For various reasons, Google is not satisfied with the current libc (glibc, musl), and the company is on its way to developing a new implementation that is proposed to be evolved as part of LLVM.
LLVM's developments have recently been used as a foundation for building Google's tooling. The main idea is that if Google has already started developing its own libc, then why not develop its system within LLVM, which already offers its standard library for C++ (Libc++), but lacks a similar standard library for C (Libc).
The development is planned to be conducted in phases, gradually increasing functionality. The initial versions are proposed to be designed as a layer between the application and the system's Libc, from which still unimplemented features will be borrowed. After reaching a certain level of functionality, the new Libc will be able to be used as a complete replacement for the system's Libc. It will start with support for the x86-64 architecture, Linux, and static linking (dynamic loading, linking, and additional architectures will be implemented second).
The project is still in its early stages, but basic goals have already been defined:
- Modularity and development in accordance with the philosophy of delivering a granular library rather than a monolithic set;
- Support for static linking in modes with (Position-independent executables) and without PIE. Providing CRT (C runtime) and PIE loader for statically linked executables;
- Support for most functions of the standard C library with POSIX extensions and some system-specific extensions required by existing applications;
- Caution regarding manufacturer-specific extensions and their addition only when necessary. For support of third-party extensions, the approach of Clang and libc+ projects is proposed;
- Utilization of best practices in development using LLVM tooling, such as applying sanitizers and fuzz testing from the very beginning.
One of the active developers of LLVM , that supplying libc as part of the LLVM toolset is not without merit, but usually, when such a need arises, the musl library is used, which is well-written, supports various architectures, and provides the necessary functionality, including support for dynamic linking. It may be justified to embed musl into LLVM and develop it as a fork synchronized with the main project.
His opinion was also by the author of the Musl project, who attempted to argue why Google's proposal to include Libc in the LLVM distribution is a very bad idea:
- Developing and maintaining a correct, compatible, and high-quality Libc is a very challenging task. The issue is not the volume of code, but ensuring correct behavior and the difficulties in implementing interfaces considering the vast array of applications written in C/C++, as well as applications in other languages whose runtime uses Libc. A blunt approach without consideration of nuances will only result in many existing programs being unable to work with Libc, making such a project unappealing to consumers.
- Corporate development can spoil Libc, but it can also push for widespread use, resulting in the need to add hacks to ensure compatibility in applications. Development under the banner of a corporate open project will lead to prioritizing the needs and solutions of the company, to the detriment of community interests. For example, in the case of identifying a problem caused by an error in its other software, it is easier to ensure Libc compatibility with that error than to fix the error itself. Apple uses a fork of BSD libc for these purposes, while Google utilizes a fork of musl in Fuchsia. The experience of the musl developer indicates that they have primarily been contacted by lawyers for licensing clarifications, but never for technical details before incorporating useless and disruptive changes into their branches.
- The lack of monoculture in the development of libc and the focus on consensus-based standards rather than unilateral control encourages application developers to adopt standards rather than tie themselves to specific implementations. This is why the author of musl opposes the inclusion of his library in the LLVM project, just as he opposes the development of libc within LLVM, as it compromises the independent nature of libc, and a specific implementation would become a first-class solution for LLVM while all others would be second-class.
Source: opennet.ru
