Fortschritte bei der Entwicklung eines GCC-basierten Rust-Compilers

Aktueller Stand der Entwicklung eines GCC-basierten Rust-Compilers

• gccrs, das GCC-basierte Rust-Compiler-Projekt, wurde 2014 gestartet und hat das Ziel, einen Rust-Compiler innerhalb der GNU Compiler Collection (GCC) zu implementieren.
• Das Ziel von gccrs war die Aufnahme in das Release von GCC 13, was jedoch nicht erreicht wurde. Derzeit wird die Aufnahme in GCC 14 angestrebt, dessen Veröffentlichung für Mitte 2024 erwartet wird.
• gccrs zielt auf Rust Version 1.49 ab, also die letzte Version vor der Einführung von const generics.
• Eines der wichtigen Prinzipien des gccrs-Projekts ist es, kein „Superset“ von Rust zu schaffen, sondern die Ausgabe von rustc unverändert zu reproduzieren.
• Die Rust-Standardbibliothek besteht aus mehreren „Crates“, und gccrs konzentriert sich darauf, die Kompilierung der Crates core und alloc zu unterstützen.
• gccrs kann diese Crates derzeit aufgrund mehrerer fehlender Funktionen noch nicht kompilieren; Probleme sind unter anderem das Fehlen eines Borrow Checkers und fehlende LLVM Intrinsics, die von GCC nicht unterstützt werden.

Nutzung der Vorteile des GCC-Ökosystems

• Einer der Hauptgründe für die Entwicklung von gccrs ist, die Nutzung der Sicherheits-Plugins von GCC zu ermöglichen.
• gccrs wird bereits in der Homebrew-Community für die Sega Dreamcast eingesetzt und kann mithilfe von GCC-Plugins eine statische Analyse von unsafe Rust-Code durchführen.
• Durch die Arbeit an gccrs konnten zusätzliche Funktionen zur Rust-Spezifikation beigetragen werden, und man möchte sich an der Ausarbeitung der offiziellen Rust-Spezifikation beteiligen.

Funktionen in Entwicklung

• Bei gccrs fehlen weiterhin viele Kernfunktionen, darunter async/await, in GCC nicht vorhandene LLVM Intrinsics sowie das Makro format_args!().
• Das Projekt Polonius implementiert einen Borrow Checker, der die Lebensdauer von Referenzen mit einem anderen Algorithmus berechnet, um die Schwächen des aktuellen Borrow Checkers von rustc zu beheben.
• Die Arbeit am Makro format_args!() hat begonnen; es wird benötigt, um die Argumente zusammenzustellen, die an andere String-Formatierungs-Makros übergeben werden.

rustc_codegen_gcc

• rustc_codegen_gcc ist ein anderes GCC-basiertes Rust-Projekt, das reifer ist als gccrs und einen engeren Umfang hat.
• rustc_codegen_gcc verwendet die Bibliothek libgccjit, um an die LLVM-Backend-API von rustc anzubinden, und führt die Kompilierung in späten Phasen von rustc und GCC durch.
• Stand Oktober 2023 kann rustc_codegen_gcc Rust for Linux ohne zusätzliche Patches kompilieren.

Rust for Linux

• Das Projekt Rust for Linux stellt Dokumentation dazu bereit, wie sich Rust-Code für den Kernel mit rustc oder rustc_codegen_gcc bauen lässt.
• gccrs verfolgt das Ziel, Rust for Linux zu unterstützen, doch angesichts der großen Unterschiede zur derzeit unterstützten rustc-Version erscheint das aktuell noch in weiter Ferne.

Meinung von GN⁺

• Das gccrs-Projekt zielt auf eine GCC-basierte Implementierung des Rust-Compilers ab, was dem Rust-Ökosystem mehr Vielfalt bringen und vorhandene Werkzeuge wie die Sicherheits-Plugins von GCC nutzbar machen könnte.
• Obwohl gccrs zentrale Teile der Rust-Standardbibliothek noch nicht kompilieren kann, ist bemerkenswert, dass es bereits einen praktischen Einsatzfall in der Homebrew-Community der Sega Dreamcast gibt.
• Dieser Artikel bietet interessante Einblicke in verschiedene Compiler-Implementierungen für die Sprache Rust und in das Potenzial für eine Erweiterung ihres Ökosystems.

[GN⁺]

Hacker-News-Kommentare

• Zusammenfassung des ersten Kommentars:

  • Der Kommentar empfindet die im Artikel genannten Beweggründe für die Entwicklung von gccrs als schwach.
  • gccrs wird entwickelt, um die Sicherheits-Plugins von GCC nutzen zu können.
  • Die Initiative „Rust for Linux“, die Rust-Unterstützung für den Linux-Kernel hinzufügt, ist ein weiterer Grund.
  • Ein wichtiger Antrieb ist, dass viele Kernel-Entwickler den Linux-Kernel ausschließlich mit der GNU-Toolchain kompilieren möchten.
  • Warum GCC als Backend verwendet wird, wird erklärt, aber warum ein doppeltes Frontend nötig ist, wird nur unzureichend erläutert.
  • Man sollte aus den Fehlern von C++ lernen, und verschiedene Frontends erschweren die plattformübergreifende Entwicklung.
  • Es wird darauf geachtet, dass gccrs nicht zu „GNU Rust“ wird, und stattdessen versucht, die Ausgabe von rustc zu reproduzieren.

• Zusammenfassung des zweiten Kommentars:

  • Rust braucht einen Sprachstandard.
  • Viele Organisationen und Branchen würden Rust ohne Standard nicht einführen.
  • Andere Sprachen wie C, C++, C#, JavaScript (ECMAScript) haben alle einen Standard.

• Zusammenfassung des dritten Kommentars:

  • Der Kommentar ist überrascht über die negative Reaktion auf GCC-RS.
  • Wenn eine Sprache nicht mehrere Implementierungen hat, ist sie unvollständig.

• Zusammenfassung des vierten Kommentars:

  • gccrs wird Rust-Unterstützung für Architekturen ermöglichen, die von LLVM nicht unterstützt werden.

• Zusammenfassung des fünften Kommentars:

  • Der Kommentar hält es für einen Fehler, dass gccrs sogar Bugs und Eigenheiten von rustc reproduzieren will.
  • Rust hat keine offizielle Spezifikation, und die Dokumentation allein über eine einzige Referenzimplementierung ist langfristig eine Schwäche.
  • Es ist vernünftig, dafür zu sorgen, dass bestehender Code in allen Implementierungen funktioniert, aber dadurch werden auch schlechte Entscheidungen und Bugs verewigt.
  • Microsoft investiert viel Aufwand, damit alte Programme weiterhin laufen.
  • Rust sollte sich diese Last nicht schon früh in der Sprachentwicklung aufbürden.
  • Damit sich die Sprache weiterentwickeln kann, muss sie QA und QC akzeptieren.
  • Sprachen mit starken Standards akzeptieren diese Grundhaltung.

• Zusammenfassung des sechsten Kommentars:

  • Danke für das Posten des lwn.net-Links; er hat daran erinnert, das Abonnement zu verlängern.

• Zusammenfassung des siebten Kommentars:

  • Linux kann bereits mit clang kompiliert werden.
  • Diese doppelte Entwicklungs- und Wartungsarbeit für GNU-„Reinheit“ scheint den Aufwand nicht wert zu sein.