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

Ein Entwickler von Google hat in der LLVM-Mailingliste das Thema der plattformübergreifenden Entwicklung einer Standard-C-Bibliothek (Libc) im Rahmen des LLVM-Projekts angesprochen. Aus verschiedenen Gründen ist Google mit den derzeitigen libc (glibc, musl) unzufrieden, und das Unternehmen ist auf dem Weg, eine neue Implementierung zu entwickeln, die als Teil von LLVM weiterentwickelt werden soll.

Die LLVM-Entwicklungen werden zunehmend als Grundlage für die Erstellung von Google-Bautools verwendet. Die Hauptidee ist, dass, wenn Google bereits damit begonnen hat, seine eigene libc zu entwickeln, es sinnvoll wäre, auch sein System innerhalb von LLVM weiterzuentwickeln, das bereits eine eigene Standardbibliothek für C++ (Libc++) anbietet, jedoch keine ähnliche Standardbibliothek für C (Libc).

Die Entwicklung soll schrittweise erfolgen, wobei die Funktionalität allmählich erweitert wird. Die ersten Versionen sollen als eine Schicht zwischen der Anwendung und der System-Libc gestaltet werden, aus der noch nicht implementierte Funktionen übernommen werden. Nach Erreichung eines bestimmten Funktionsniveaus kann die neue Libc als vollständiger Ersatz für die System-Libc verwendet werden. Geplant ist zunächst die Unterstützung der Architektur x86-64, Linux und die statische Verlinkung (dynamisches Laden, Linken und zusätzliche Architekturen werden in einem zweiten Schritt umgesetzt).

Das Projekt befindet sich noch in der Anfangsphase, hat jedoch bereits grundlegende Ziele definiert:

• Modularität und Entwicklung gemäß der Philosophie, eine granulare Bibliothek bereitzustellen, anstatt ein monolithisches Set zu liefern;
• Unterstützung der statischen Verlinkung in Modi mit PIE (Positionsunabhängige ausführbare Dateien) und ohne PIE. Bereitstellung von CRT (C-Laufzeit) und Loader für PIE für statisch verlinkte ausführbare Dateien;
• Unterstützung der meisten Funktionen der Standard-C-Bibliothek mit POSIX-Ergänzungen und einigen systemabhängigen Erweiterungen, die in bestehenden Anwendungen gefordert sind;
• Vorsichtiger Umgang mit herstellerspezifischen Erweiterungen und deren Hinzufügung nur bei Bedarf. In Bezug auf die Unterstützung von Drittanbietererweiterungen wird vorgeschlagen, den Ansatz der Projekte Clang und libc++ anzuwenden;
• Verwendung bewährter Praktiken in der Entwicklung unter Verwendung von LLVM-Tools, wie die Anwendung von Sanitizern und Fuzzing-Tests von Anfang an.

Einer der aktiven Entwickler von LLVM wies darauf hin, dass die Lieferung von libc im Rahmen des LLVM-Toolkits sinnvoll ist, aber normalerweise bei einem solchen Bedarf die musl-Bibliothek verwendet wird, die qualitativ hochwertig geschrieben ist, verschiedene Architekturen unterstützt und die erforderliche Funktionalität bietet, einschließlich der Unterstützung für dynamisches Binden. Es kann gerechtfertigt sein, musl in LLVM zu integrieren und es als synchronisierten Fork des Hauptprojekts weiterzuentwickeln.

Seine Meinung hat auch ausgedrückt der Autor des Musl-Projekts, der versucht hat zu argumentieren, warum Googles Vorschlag und die Einbeziehung von Libc in die LLVM-Lieferung sehr schlechte Ideen sind:

• Die Entwicklung und Wartung einer korrekten, kompatiblen und hochwertigen Libc ist eine sehr schwierige Aufgabe. Das Problem liegt nicht im Umfang des Codes, sondern in der Gewährleistung korrektes Verhaltens und den Schwierigkeiten bei der Implementierung von Schnittstellen angesichts des riesigen Rückstands an jemals geschriebenen Anwendungen in C/C++ sowie Anwendungen in anderen Sprachen, deren Laufzeit Libc verwendet. Ein frontaler Ansatz ohne Berücksichtigung von Nuancen führt nur dazu, dass viele bestehende Programme nicht mit Libc arbeiten können, was das Projekt für die Nutzer unattraktiv macht.
• Die Unternehmensentwicklung kann Libc verderben, aber für eine breitere Anwendung durchdringen, was dazu führt, dass Hacks hinzugefügt werden müssen, um die Kompatibilität in den Anwendungen sicherzustellen. Die Entwicklung unter dem Banner eines unternehmenseigenen Open-Source-Projekts wird die Bedürfnisse und Lösungen des Unternehmens priorisieren, zum Nachteil der Interessen der Gemeinschaft. Zum Beispiel, wenn ein Problem identifiziert wird, das durch einen Fehler in einem anderen eigenen Programm verursacht wurde, ist es in der kontrollierten Entwicklung einfacher, die Kompatibilität von Libc mit diesem Fehler sicherzustellen, als den Fehler selbst zu beheben. Apple verwendet dafür einen Fork von BSD libc, während Google in Fuchsia einen Fork von musl einsetzt. Die Erfahrung des Entwicklers von musl zeigt, dass sich hauptsächlich Juristen zur Klärung von Lizenzfragen mit ihm in Verbindung gesetzt haben, aber nie für technische Details, bevor sie nutzlose und funktionsstörende Änderungen in ihre Abzweigungen übernahmen.
• Das Fehlen einer Monokultur bei der Entwicklung von libc und die Ausrichtung auf konsensbasierte Standards anstelle von zentraler Kontrolle motivieren Entwickler von Anwendungen dazu, Standards zu nutzen, anstatt sich an spezifische Implementierungen zu binden. Daher spricht sich der Autor von musl gegen die Einbeziehung seiner Bibliothek in LLVM aus, ebenso wie gegen die Entwicklung von libc im Rahmen von LLVM, da in diesem Fall der unabhängige Charakter von libc verloren geht und eine bestimmte Implementierung zur bevorzugten Lösung für LLVM wird, während alle anderen darunter fallen.

Quelle: opennet.ru