Entwickler von Google haben vorgeschlagen, eine eigene libc für LLVM zu entwickeln.

Einer der Entwickler von Google hat das Thema in der LLVM-Newsletterliste zur Entwicklung einer plattformübergreifenden Standard-C-Bibliothek (Libc) im Rahmen des LLVM-Projekts angesprochen. Aus verschiedenen Gründen ist Google mit den aktuellen libc-Implementierungen (glibc, musl) nicht zufrieden und arbeitet an der Entwicklung einer neuen Lösung, die als Teil von LLVM weiterentwickelt werden soll.

Die aktuellen Arbeiten an LLVM werden zunehmend als Grundlage für die Entwicklung von Google-Bautools verwendet. Die Grundidee ist, dass, wenn Google bereits mit der Entwicklung seiner libc begonnen hat, es auch sinnvoll wäre, sein System innerhalb von LLVM zu entwickeln, das bereits seine eigene Standardbibliothek für C++ (Libc++) anbietet, jedoch keine ähnliche Standardbibliothek für C (Libc) hat.

Die Entwicklung soll schrittweise und nach und nach mit einer erweiterten Funktionalität erfolgen. Die ersten Varianten sind als eine Schicht zwischen der Anwendung und der systemeigenen Libc geplant, aus der noch nicht implementierte Funktionen entnommen werden. Nach Erreichen eines bestimmten Funktionslevels könnte die neue Libc als vollständiger Ersatz für die systemeigenen Libc verwendet werden. Geplant ist zunächst die Unterstützung der Architektur x86-64, Linux und statisches Linking (dynamisches Laden, Linking und zusätzliche Architekturen werden in einem zweiten Schritt realisiert).

Das Projekt befindet sich noch in der Anfangsphase, aber die grundlegenden Ziele sind bereits definiert:

• Modularität und Entwicklung gemäß der Philosophie der Bereitstellung einer granularen Bibliothek statt eines monolithischen Sets;
• Unterstützung von statischem Linking in Modi mit PIE (Position-independent executables) und ohne PIE. Bereitstellung von CRT (C-Laufzeit) und Loader für PIE für statisch linkbare ausführbare Dateien;
• Unterstützung der meisten Funktionen der Standard-C-Bibliothek mit Ergänzungen aus POSIX und einigen systemabhängigen Erweiterungen, die in bestehenden Anwendungen nachgefragt werden;
• Ein vorsichtiger Umgang mit herstellerspezifischen Erweiterungen und deren Hinzufügung nur bei Bedarf ist ratsam. Bei der Unterstützung von Drittanbietererweiterungen sollte der Ansatz der Clang- und libc+-Projekte angewendet werden.
• Die Anwendung bewährter Praktiken in der Entwicklung unter Verwendung von LLVM-Tools, wie die Implementierung von Sanisierern und Fuzzing-Tests von Anfang an.

Einer der aktiven Entwickler von LLVM erwähnt wurde, wodurch die Bereitstellung von libc im Rahmen des LLVM-Toolsets durchaus sinnvoll ist. Allerdings wird bei solch einem Bedarf in der Regel die musl-Bibliothek verwendet, die qualitativ hochwertig geschrieben ist, verschiedene Architekturen unterstützt und die notwendige Funktionalität bietet, einschließlich der Unterstützung von dynamischem Linking. Die Einbettung von musl in LLVM und die Entwicklung als synchronisierter Fork des Hauptprojekts kann sinnvoll sein.

Seine Meinung hat auch geäußert der Autor des Musl-Projekts, der versucht hat zu argumentieren, warum das Angebot von Google und die Einbeziehung von Libc in die LLVM-Auslieferung sehr schlechte Ideen sind:

• Die Entwicklung und Unterstützung einer korrekten, kompatiblen und qualitativ hochwertigen Libc ist eine anspruchsvolle Aufgabe. Es geht nicht nur um den Umfang des Codes, sondern um die Gewährleistung eines korrekten Verhaltens und die Herausforderungen bei der Implementierung von Schnittstellen, angesichts der Vielzahl bereits geschriebener Anwendungen in C/C++ sowie in anderen Sprachen, deren Runtime Libc verwendet. Ein pauschaler Ansatz ohne Berücksichtigung dieser Nuancen würde dazu führen, dass viele bestehende Programme nicht mit Libc kompatibel sind, was das Projekt für die Verbraucher uninteressant machen würde.
• Die Entwicklung im Unternehmenskontext kann die Libc beeinträchtigen, um eine breitere Nutzung zu ermöglichen, was zur Notwendigkeit führt, Hacks hinzuzufügen, um die Kompatibilität in Anwendungen zu gewährleisten. Eine Entwicklung unter dem Banner eines Unternehmensprojekts wird die Bedürfnisse und Lösungen des Unternehmens über die Interessen der Gemeinschaft stellen. Zum Beispiel ist es einfacher, die Libc mit einem Fehler in einem anderen Programm, den das Unternehmen kontrolliert, kompatibel zu machen, als den Fehler selbst zu beheben. Apple verwendet dafür einen Fork der BSD libc, während Google in Fuchsia einen Fork von musl anwendet. Die Erfahrungen des musl-Entwicklers zeigen, dass vor allem Juristen wegen Lizenzfragen Kontakt aufgenommen haben, aber nie technischer Support angefragt wurde, bevor fehlerhafte und funktionsgestörte Änderungen in ihre Forks übernommen wurden.
• Die Abwesenheit einer Monokultur bei der Entwicklung von libc und die Orientierung an Konsens-basierten Standards, statt an einer zentralen Steuerung, motiviert Entwickler von Anwendungsprogrammen, diese Standards zu nutzen, anstatt sich an spezifische Implementierungen zu klammern. Aus diesem Grund lehnt der Autor von musl die Einbeziehung seiner Bibliothek in LLVM ab, ebenso wie die Entwicklung von libc im Rahmen von LLVM, da hierbei die Unabhängigkeit von libc verloren ginge und eine bestimmte Implementierung zur erstklassigen Lösung für LLVM und alle anderen zu zweitklassigen Lösungen würde.

Quelle: opennet.ru