One of the developers from Google raised on the LLVM mailing list the topic of developing a multi-platform standard C-library (Libc) within the framework of the LLVM project. For a number of reasons, Google is not satisfied with the current libc (glibc, musl) and the company is on its way to developing a new implementation, which is proposed to be developed as part of LLVM.
LLVM developments have recently been used as the basis for building Google’s assembly tools. The main idea is that if Google has already begun to develop its libc, then why not immediately develop its system as part of LLVM, which already offers its standard library for C ++ (Libc ++), but does not have a similar standard library for C ( Libc).
Development is planned to be phased, gradually increasing functionality. The first options are proposed to be in the form of a layer between the application and the system libc, from which the unrealized features will be borrowed. After reaching a certain level of functionality, the new Libc can be used as a complete replacement for the system Libc. It is planned to start with the support of x86-64 architecture, Linux and static binding (dynamic loading, packaging, and additional architectures will be implemented in the second place).
The project is still at the initial stage of development, but the basic goals have already been defined:
- Modularity and development in accordance with the philosophy of supplying a granular library, rather than a monolithic set;
- Static binding support in modes with PIE (Position-independent executables) and without PIE. Providing CRT (C runtime) and PIE loader for statically linked executable files;
- Support for most of the functions of the standard C library with POSIX add-ons and some system-specific extensions in demand in existing applications;
- Careful attitude to vendor-specific extensions and adding them only when necessary. For support for third-party extensions, it is proposed to use the Clang and libc ++ projects approach;
- Using exemplary practices in development using LLVM tools, such as applying sanitizer and fuzzing testing from the start.
One of the active developers of LLVM indicated that the delivery of libc as part of the LLVM toolkit is not devoid of meaning, but usually with such a need they use the musl library, which is well-written, supports various architectures and provides the necessary functionality, including dynamic linking. The embedding of musl in LLVM and its development as a fork synchronized with the main project can be justified.
Opinion was also expressed by the author of the Musl project, who tried to argue why the Google proposal and the inclusion of Libc in the LLVM delivery are very bad ideas:
- Developing and maintaining the correct, compatible, and high-quality libc is a very difficult task. The problem is not in the amount of code, but in providing correct behavior and difficulties with the implementation of interfaces taking into account the huge reservoir of ever written applications in C / C ++, as well as applications in other languages whose runtime is used by Libc.
- Corporate development can spoil the Libc, but push through for widespread use, the result of which will be the need to add hacks to ensure compatibility in applications. Development under the auspices of a corporate open project will pull the blanket toward the needs and decisions of the company, to the detriment of the interests of the community.
- The lack of a monoculture in the development of libc and a focus on the standards developed based on the consensus reaching, instead of sole management, motivates application developers to use the standards, rather than being tied to specific implementations. That is why the author of musl opposes the inclusion of his library into LLVM, as well as against the development of libc within LLVM, since in this case the independent nature of libc is lost and a certain implementation becomes the first-class solution for LLVM, and all others are second.
Get more info at the developers thread.