Entwickler von Google schlugen vor, eine eigene libc für LLVM zu entwickeln

Einer der Entwickler von Google angehoben auf der LLVM-Mailingliste über die Entwicklung einer plattformübergreifenden Standard-C-Bibliothek (Libc) als Teil des LLVM-Projekts. Aus mehreren Gründen ist Google mit der aktuellen libc (glibc, musl) nicht zufrieden und das Unternehmen ist auf dem Weg, eine neue Implementierung zu entwickeln, die als Teil von LLVM entwickelt werden soll.

LLVM-Entwicklungen wurden kürzlich als Grundlage für den Aufbau der Assembler-Tools von Google verwendet. Der Hauptgedanke besteht darin, dass, wenn Google bereits mit der Entwicklung seiner libc begonnen hat, sein System dann nicht sofort als Teil von LLVM entwickelt wird, das bereits eine eigene Standardbibliothek für C++ (Libc++) anbietet, aber keine ähnliche Standardbibliothek für C hat (libc).

Die Entwicklung soll schrittweise erfolgen und die Funktionalität schrittweise erhöhen. Die ersten Optionen sollen als Schicht zwischen der Anwendung und der System-Libc konzipiert werden, aus der noch nicht implementierte Funktionen übernommen werden. Ab einem bestimmten Funktionsumfang kann die neue Libc als vollständiger Ersatz für die System-Libc verwendet werden. Wir planen, mit der Unterstützung für x86-64-Architektur, Linux und statischer Verknüpfung zu beginnen (dynamisches Laden, Verknüpfung und zusätzliche Architekturen werden sekundär implementiert).

Das Projekt befindet sich noch im Anfangsstadium der Entwicklung, grundlegende Ziele sind jedoch bereits definiert:

• Modularität und Entwicklung im Einklang mit der Philosophie, eine granulare Bibliothek anstelle eines monolithischen Satzes bereitzustellen;
• Unterstützung für statische Verknüpfung in Modi KUCHEN (Positionsunabhängige ausführbare Dateien) und ohne PIE. Bereitstellung von CRT (C-Laufzeit) und PIE-Loader für statisch verknüpfte ausführbare Dateien;
• Unterstützung für die meisten Standardfunktionen der C-Bibliothek, mit POSIX-Ergänzungen und einigen systemspezifischen Erweiterungen, die für bestehende Anwendungen erforderlich sind;
• Seien Sie vorsichtig mit herstellerspezifischen Erweiterungen und fügen Sie diese nur bei Bedarf hinzu. Bezüglich der Unterstützung von Erweiterungen Dritter wird vorgeschlagen, den Ansatz der Clang- und libc++-Projekte zu verwenden;
• Verwendung von Best Practices in der Entwicklung mithilfe des LLVM-Toolkits, z. B. Verwendung von Sanitizer- und Fuzz-Tests von Anfang an.

Einer der aktiven LLVM-Entwickler angezeigtEs ist klar, dass es sinnvoll ist, libc als Teil des LLVM-Toolkits auszuliefern, aber normalerweise wird bei Bedarf die musl-Bibliothek verwendet, die gut geschrieben ist, verschiedene Architekturen unterstützt und die erforderliche Funktionalität bereitstellt, einschließlich Unterstützung für Dynamik Verlinkung. Es kann gerechtfertigt sein, musl in LLVM einzubetten und es als mit dem Hauptprojekt synchronisierte Abzweigung zu entwickeln.

Auch deine Meinung ausgedrückt Der Autor des Musl-Projekts, der zu argumentieren versuchte, warum der Vorschlag von Google und die Aufnahme von Libc in die LLVM-Distribution sehr schlechte Ideen sind:

• Die Entwicklung und Pflege einer korrekten, kompatiblen und qualitativ hochwertigen Libc ist eine sehr schwierige Aufgabe. Das Problem liegt nicht in der Menge des Codes, sondern darin, korrektes Verhalten und Schwierigkeiten bei der Implementierung von Schnittstellen sicherzustellen, wenn man die große Menge an Anwendungen berücksichtigt, die jemals in C/C++ geschrieben wurden, sowie Anwendungen in anderen Sprachen, deren Laufzeit verwendet wird von Libc. Ein frontaler Ansatz ohne Berücksichtigung der Nuancen führt nur dazu, dass viele bestehende Programme nicht mit Libc zusammenarbeiten können, ein solches Projekt dann aber für Verbraucher nicht von Interesse ist.
• Unternehmensentwicklung kann Libc ruinieren, es aber zu einer breiten Nutzung vorantreiben, was dazu führt, dass Hacks hinzugefügt werden müssen, um die Kompatibilität in Anwendungen sicherzustellen. Die Entwicklung unter der Schirmherrschaft eines unternehmensweiten Open-Source-Projekts wird den Fokus auf die Bedürfnisse und Lösungen des Unternehmens richten, zum Nachteil der Interessen der Gemeinschaft. Wenn Sie beispielsweise ein Problem identifizieren, das durch einen Fehler in einem anderen Programm verursacht wird, ist es bei der kontrollierten Entwicklung einfacher sicherzustellen, dass Libc mit diesem Fehler kompatibel ist, als den Fehler selbst zu beheben. Apple verwendet für diese Zwecke den BSD-Libc-Fork und Google den Musl-Fork in Fuchsia. Der Musl-Entwickler hat die Erfahrung gemacht, dass er hauptsächlich von Anwälten kontaktiert wurde, um Lizenzfragen zu klären, jedoch nie, um technische Details zu klären, bevor er nutzlose und störende Änderungen an seinen Zweigen vornahm.
• Das Fehlen einer Monokultur in der libc-Entwicklung und der Fokus auf konsensgesteuerte Standards statt individueller Kontrolle, was Anwendungsentwickler dazu motiviert, Standards zu verwenden, anstatt an bestimmte Implementierungen gebunden zu sein. Aus diesem Grund ist der Autor von musl sowohl gegen die Aufnahme seiner Bibliothek in LLVM als auch gegen die Entwicklung von libc innerhalb von LLVM, da in diesem Fall die Unabhängigkeit von libc verloren geht und eine bestimmte Implementierung zu einer erstklassigen Lösung für wird LLVM und alle anderen werden zu einer zweitklassigen Lösung.

Source: opennet.ru