One of the developers from Google on the LLVM mailing list on the topic of developing a multiplatform standard C library (Libc) within 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 started developing 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 carried out in stages, gradually increasing functionality. The first options are proposed to be designed as a layer between the application and the system Libc, from which not yet implemented 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. The plan is to start with support for x86-64 architecture, Linux, and static linking (dynamic loading, linking, and additional architectures will be implemented later).
The project is still at the initial stage of development, but the basic goals have already been determined:
- Modularity and development in accordance with the philosophy of supplying a granular library, not 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 of the functions of the standard C library with POSIX additions and some system-specific extensions required by existing applications;
- Be wary of vendor-specific extensions and only add them when needed. With regard to support for third-party extensions, it is proposed to follow the approach of the Clang and libc++ projects;
- Using best practices in LLVM development, such as applying sanitizer and fuzz testing from the start.
One of the active developers of LLVM It is worth pointing out that supplying libc as part of the LLVM toolkit is not unreasonable, but usually, when necessary, they use the musl library, 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 in sync with the main project.
Your opinion also the author of the Musl project, who tried to argue why the suggestion by Google and the inclusion of Libc in the LLVM distribution are very bad ideas:
- Developing and maintaining a correct, compatible, and high quality libc is a very difficult task. The problem is not the amount of code, but the problem of ensuring correct behavior and difficulties in implementing interfaces, given the huge amount of C/C++ applications ever written, as well as applications in other languages, whose runtime uses Libc. A head-on approach without taking into account the nuances will only lead to the fact that many existing programs will not be able to work with Libc, but then such a project will not be of interest to consumers.
- Enterprise development can mess up Libc but push it into widespread use, resulting in the need to add hacks to ensure application compatibility. Developing under the auspices of a corporate open source project will pull the blanket in the direction of the needs and decisions of the company, to the detriment of the interests of the community. For example, if a problem is discovered that is caused by a bug in another of its programs, it is easier for the controlled development to make Libc compatible with that bug than it is to fix the bug itself. Apple uses a fork of BSD libc for this purpose, and Google uses a fork of musl in Fuchsia. The experience of the musl developer is that he was contacted mainly by lawyers to clarify licensing issues, but never to clarify technical details before making useless and disruptive changes to their branches.
- The lack of a monoculture in libc development and a focus on consensus-driven standards rather than sole control encourages application developers to use standards rather than being tied to specific implementations. That is why the author of musl is against the inclusion of his library in 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 a first-class solution for LLVM, and all the rest - the second.
Source: opennet.ru