+1! Avr-Rost, der in den eigentlichen Compiler integriert ist, wäre sehr nützlich. Es ist jetzt fast fehlerfrei.

Nicht ganz fehlerfrei :)

Ich werde die Beschreibung aktualisieren, um einige Informationen über den Status des Backends bezüglich Fehlern aufzunehmen

Fast doch 😄. Nur noch ein paar

Im Allgemeinen begrüßen wir Upstream-Plattformen in rust-lang/rust sehr, solange sie uns nicht mit der Wartung belasten! Einige spezifische Gedanken aus dem, was Sie denken:

• Rosinenpicken von LLVM-Commits von Zeit zu Zeit ist völlig in Ordnung, ich denke, Sie haben den Prozess auch schon ein paar Mal durchlaufen :)
• Fehlende intrinsische Elemente in Compiler-rt ist für uns in Ordnung, Sie haben die Möglichkeit, diese über das Compiler-Builtins-Projekt auch in Rust zu implementieren.
• Der Patch, den Sie haben, sieht ziemlich gut aus, obwohl ich denke, dass wir die verschiedenen #[cfg] in libcore mehr durcharbeiten möchten. Werden diese Elemente aufgrund von "Bugs in LLVM" weggelassen oder weil sie von AVR grundsätzlich nicht unterstützt werden? Ersteres würde am besten durch "Reparieren von LLVM" erreicht, während letzteres die Dinge schwieriger macht.

Im Allgemeinen haben wir derzeit alle Plattformen mit der gleichen einheitlichen Schnittstelle von libcore/libstd, aber es ist nicht klar, dass dies auch so bleiben wird, da wir immer mehr Plattformen aufnehmen.

Der Patch, den Sie haben, sieht ziemlich gut aus, obwohl ich denke, dass wir die verschiedenen #[cfg] in libcore mehr durcharbeiten möchten. Werden diese Elemente aufgrund von "Bugs in LLVM" weggelassen oder weil sie von AVR grundsätzlich nicht unterstützt werden?

Es liegt an Fehlern in LLVM.

Die einzige Frage, die mir in den Sinn kommt, ist die Unterstützung von i128 / u128 -Typen - ich denke, dass diese für AVR nicht wirklich nützlich sind. Die i128 Unterstützung in libcore ist derzeit wegen eines Fehlers auskommentiert, aber es kann noch andere unentdeckte Fehler geben, da es sich nicht um einen gut getesteten Codepfad handelt und den Registerzuordner wirklich nur als AVR ausübt hat einen Wert von 32 Byte an Universalregistern.

Es ist immer noch ziemlich wahrscheinlich, dass wir i128 dazu bringen könnten, an AVR zu arbeiten, aber ich weiß nicht viel über die spezifischen Probleme, die es im Backend auslöst.

Ich denke, der beste Weg wäre, den Patch wirklich vorzuschlagen, sobald libcore ohne Modifikation _kompiliert_, oder zumindest ohne viele.

Ich denke, dass der beste Weg nach vorne darin besteht, den Patch wirklich vorzuschlagen, sobald libcore ohne Modifikationen oder zumindest ohne viele Änderungen kompiliert wird.

Klingt für mich vernünftig!

Die einzige Frage, die ich im Kopf habe, ist die Unterstützung von i128/u128-Typen - ich denke, dass diese für AVR nicht wirklich nützlich sind.

Meine größte Befürchtung, i128 auf AVR nicht zu unterstützen, besteht darin, dass dies eine abschreckende Wirkung auf die Übernahme von 128-Bit-Ganzzahlen aus Gründen der Kompatibilität mit AVR oder anderen eingebetteten Plattformen haben wird. Wenn es zB eine Bibliothek gibt, die 128-Bit-Ganzzahlen verwendet, werden AVR-Benutzer, die sie verwenden möchten, Probleme melden, um die Verwendung einzustellen. Dies kann dazu führen, dass 128-Bit-Ganzzahlen nicht "sicher" in Rust-Code verwendet werden, der portabel ist, was ich nicht möchte.

eine abschreckende Wirkung bei der Übernahme von 128-Bit-Ganzzahlen aus Gründen der Kompatibilität mit AVR oder anderen eingebetteten Plattformen

Ich glaube nicht, dass es hier eine besonders große Sache ist. Kleine eingebettete Geräte haben bereits riesige Einschränkungen (kein stdin / stdout, im Allgemeinen kein Allocator usw.), die es wirklich schwierig machen, einfach eine beliebige Bibliothek einzufügen. Ich habe vor kurzem erfahren, dass double AVR GCC eigentlich ein Alias ​​für float ! Ich weiß nicht, ob wir diese Seltsamkeit beibehalten werden oder nicht, aber es würde Kisten weit mehr als i128 betreffen.

Ich denke, wir werden immer spezielle Funktionen haben, die verwendet werden, um eine Crate für Embedded geeignet zu machen, genau wie wir es für No-Std.

kein stdin / stdout, generell kein Allocator usw.

Sie beschreiben das Ökosystem #![no_std] . Es gibt Bibliotheken, die auf dieses Ökosystem abzielen. Und die allgemeine Regel für dieses Ökosystem ist, libcore als gegeben anzunehmen, was auch i128 einschließt. Jedes Ziel, das i128 nicht unterstützt, hat einen größeren abschreckenden Effekt innerhalb dieses Ökosystems, da der "Marktanteil" eines eingebetteten Ziels innerhalb der Teilmenge des gesamten Rust-Ökosystems größer ist, wo die x86-Familie kein sehr relevanter Akteur ist .

Ich weiß nicht, ob wir diese Seltsamkeit beibehalten werden oder nicht, aber es würde Kisten viel mehr als 128 betreffen.

Interessant! Ich stimme zu, dass es das Ökosystem stärker beeinträchtigen würde, wenn wir f64 bis f32 (oder es nicht bereitstellen würden). Wenn wir jedoch nach Konsistenz streben können, warum sollten wir dann nicht? Es ist uns durchaus möglich, i128 zu implementieren.

Es ist uns durchaus möglich i128 zu implementieren.

Absolut, und mir ist klar, dass ich nicht klar gesagt habe, dass wir tatsächlich ein i128 auf einem AVR verwendet, wird jedoch eine Welt voller Schmerzen erleben.

Wenn wir jedoch nach Konsistenz streben können, warum sollten wir dann nicht?

Konsistenz mit dem , f64 == f32 ) oder mit jedem anderen Rust-Ziel ( f64 != f32 )?

Sie beschreiben das #![no_std]-Ökosystem.

Ja, deshalb sagte ich "besondere Funktionen, die verwendet werden, um eine Kiste für Embedded geeignet zu machen, genau wie wir es für No-Std tun." 😇

Ein größeres Problem, das ich im Hinterkopf habe, seit wir ursprünglich den 16-Bit-Patch usize besteht darin, dass Rust- und Rust-Programmierer grundsätzlich davon ausgehen, dass usize der "native" Größe eines Registers. AFAIK, dies gilt für alle anderen Plattformen von Rust-Zielen, aber nicht für AVR.

Konsistenz mit was, ist die Frage. Konsistenz mit GCC (f64 == f32) oder mit jedem anderen Rust-Target (f64 != f32)?

Der Name f64 wörtlich, dass es 64 Bit hat. Wenn Sie sich nicht an den Namen halten, wird er wie in C bedeutungslos.

Gute Punkte hier, ich kann die Besorgnis um 128-Bit-Ganzzahlen sehen. Ich denke definitiv, dass sie unterstützt werden sollten, auch wenn wir ihre Verwendung nicht ermutigen sollten. Ich würde es hassen, wenn Kisten Feature-Flags für Dinge wie Trait-Impls auf i128 Typen hinzufügen müssten. Dies sollte kein wirkliches Problem sein, da das gesamte nicht verwendete i128-Zeug vom Linker entfernt werden sollte.

Das Problem f32/64 ist interessant. Mein Hauptanliegen bei der Erstellung von f64 tatsächlich 64-Bit ist, dass dies bedeutet, dass C FFI sehr spröde sein könnte. Wenn Entwickler nicht wissen, dass AVR-GCC 32-Bit-Doubles verwendet, könnten Aufrufe über FFI nicht initialisierten Speicher oder Segfault lesen.

Ich kann mir vorstellen, dass wir dies mehr oder weniger lösen könnten, indem wir erwarten, dass Benutzer stattdessen Typen aus der libc Kiste verwenden. Wir könnten AVR-spezifische Funktionen hinzufügen, um c_double auf f32 . Ich denke, wir können vernünftigerweise erwarten, dass die Leute die libc Kiste in ihren FFI-Bindungen verwenden.

Etwas, das Sie sich beim Zusammenführen merken müssen, Sie müssen den c_int Typ aktualisieren, der in der main() Signatur verwendet wird: https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Bearbeiten: dafür ein Problem geöffnet, da es auch MSP430 betrifft: https://github.com/rust-lang/rust/issues/44934

in der main()-Signatur verwendet

@mattico Vielleicht habe ich nur Dinge auf seltsame Weise gemacht, aber keiner meiner Codes hat Rusts main :

#[no_mangle]
pub extern fn main() {

Noch wichtiger ist , können wir Rückkehr nicht wirklich , weil es nichts zurückzukehren ist. Jedes Programm muss ewig laufen.

@mattico Wir werden die libc definitiv noch ändern müssen, damit die Typen mit GCC für AVR übereinstimmen

Oh, absolut, ich weiß einfach nicht, dass main uns überhaupt beeinflussen wird.

@shepmaster Sogar auf nicht eingebetteten Plattformen spielt die Größe von argc in main keine Rolle, da wir die ganze Zeit falsch lagen und niemand außer bei der Inspektion des IRs bemerkt hat. Es kann einige RTOS geben, die einen standardmäßigen main()-Einstiegspunkt für ihre Prozesse verwenden? Unabhängig davon ist es einfach genug zu beheben.

Es hätte wahrscheinlich genauso lange gedauert, einen Fix einzureichen, wie es dauerte, dies abzutippen, jetzt wo ich darüber nachdenke 😄

Sind es nur die libcore-Probleme, die diese Zusammenführung verhindern? Nur damit wir wissen, worauf wir unsere Anstrengungen konzentrieren müssen.

Die einzigen Probleme, die ich mit libcore hatte, waren seltsame Linker-Fehler, die durch Ich weiß nicht was verursacht wurden, und auch 32-Bit-Bitverschiebungsfehler (fehlen intrinsisch, denke ich). Ich weiß jedoch nicht, ob diese die Zusammenführung blockieren.

chocol4te: Sind es nur die libcore-Probleme, die diese Zusammenführung verhindern? Nur damit wir wissen, worauf wir unsere Anstrengungen konzentrieren müssen.

Ja – alle hier erforderlichen Arbeiten müssen innerhalb von LLVM ausgeführt werden .

Restioson: Die einzigen Probleme, die ich mit libcore hatte, waren seltsame Linker-Fehler, die durch Ich weiß nicht was verursacht wurden, und auch 32-Bit-Bitverschiebungsfehler (fehlen intrinsisch, denke ich).

Das liegt daran, dass der gesamte Code, der den AVR-Backend-Drossel verursacht, auskommentiert ist :)

Restioson: Ich weiß jedoch nicht, ob diese die Zusammenführung blockieren.

Nicht direkt, aber es wäre gut, das Problem behoben zu haben, bevor das Backend zusammengeführt wird. Es gibt ein paar wirklich nervige Fehler wie diesen, die wir vor dem Zusammenführen in Betracht ziehen sollten, um sie zu beheben, aber sie müssen nicht unbedingt aufhalten.

@dylanmckay LLVM6 wurde zusammengeführt https://github.com/rust-lang/rust/pull/47828 - was bedeutet das für diesen RFC?

@kellerkindt alle unter "Aktuelle Probleme im AVR-Backend" aufgeführten Probleme sind weiterhin zutreffend. Es ist wahrscheinlich, dass der aktuelle HEAD von avr-rust umbasiert und der interessante Rust-spezifische Code zusammengeführt werden könnte, aber das bringt immer noch keinen funktionierenden Code.

Ich persönlich bin immer noch dafür

Ich denke, dass der beste Weg nach vorne darin besteht, den Patch wirklich vorzuschlagen, sobald libcore ohne Modifikationen oder zumindest ohne viele Änderungen kompiliert wird.

Obwohl es schön ist , zusätzliches Rebasing vermeiden zu müssen.

Ich frage mich den aktuellen Stand von Rust auf AVR, jetzt wo wir ein halbes Jahr später in der Entwicklung sind. Ich betreibe eine kleine Arduino-Projektgruppe in meiner Stadt und würde _liebe_, stattdessen Rust verwenden zu können.

Also, gute Nachrichten!

Ich denke, dass der beste Weg nach vorne darin besteht, den Patch wirklich vorzuschlagen, sobald libcore ohne Modifikationen oder zumindest ohne viele Änderungen kompiliert wird.

Dies ist jetzt der Fall!

Die aktuelle avr-rust Gabel enthält keine Änderungen an libcore .

Die Modifikationen, die erforderlich sind, um AVR von Stock Rus zu unterstützen, sind:

• Die AVR-Backend-Initialisierungsfunktionen LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} werden deklariert und aufgerufen.
• Eine Basis-Minimum-Avr-Zielspezifikation avr-unknown-unknown wurde hinzugefügt. Dies modelliert das Standardverhalten von avr-gcc beim Bauen für den kleinsten gemeinsamen Nenner, sofern nicht ausdrücklich angegeben. Im Gegensatz zu avr-gcc das explizit das Argument -mmcu=<avr mcu name> , wurde kein AVR-spezifisches Befehlszeilenargument für AVR hinzugefügt. Dies bedeutet, dass für jedes Projekt eine benutzerdefinierte Zielspezifikations-JSON-Datei geschrieben werden muss. Dies ist jedoch bei vielen in Rust eingebetteten Projekten der Fall.
• Im Fork wird das AVR LLVM-Backend immer kompiliert und im Standard-Rust-Checkout verlinkt und der config.toml.example Datei hinzugefügt. Sollte AVR standardmäßig im Upstream Rust enthalten sein oder sollte es auch opt-in sein?
• AVR-spezifische Logik zum Compiler hinzugefügt, wo dies für alle neuen Ziele erforderlich ist
• Die Aufrufkonvention "avr-interrupt" wurde hinzugefügt. Dies ermöglicht extern "avr-interrupt" fn my_isr_handler() { .. } . Dies müsste wahrscheinlich den RFC-Prozess durchlaufen, um sich zu stabilisieren, aber ich könnte mich irren.
• Unterstützung für eine bedingte Kompilierung auf der CPU, a la #[cfg(target_cpu = "...")] wurde hinzugefügt. Die Umsetzung finden Sie hier . Die Implementierung ist zielunabhängig und funktioniert somit auch für andere Architekturen wie ARM für die bedingte Kompilierung basierend auf der CPU. Dadurch kann die ruduino Kiste bedingt ein gerätespezifisches Modul enthalten, das alle IOs, Register und Module verfügbar macht, die im Silizium unterstützt werden. Dies muss auf jeden Fall vor dem Upstream den RFC-Prozess durchlaufen.

Es ist wahrscheinlich an der Zeit, dass ich einen RFC an LLVM-dev schicke, um das Backend in den nicht experimentellen Status zu befördern.

Sie können die vollständigen Änderungen von Upstream Rust zu avr-rust hier sehen .

Es gibt noch ein paar LLVM-Patches aus den letzten zwei Monaten, die wir im Moment ausgewählt haben, aber die Bemühungen des Upstream-Rust, die Emscripten-Version von LLVM von der Version von LLVM zu trennen, die für alle anderen Ziele verwendet wird, haben es wirklich einfach gemacht, sie zu bringen Diese Änderungen stammen aus dem rust-lang/llvm Repo, da es jetzt regelmäßig aktualisiert wird.

Die <4 ausgewählten LLVM-Patches, die wir haben, werden derzeit in Upstream-LLVM überprüft, und sobald ein Reviewer genug Zeit findet, werden diese Patches automatisch in Upstream-Rust übertragen. Upstream Rust hat auch zielspezifische Rust-spezifische Patches, und so sind LLVM-Patches wahrscheinlich nicht wirklich ein Blocker für das Zusammenführen von avr-rust Upstream

Gibt es ein Update zum Status von Rust auf AVR?

Auch interessiert zu wissen! Im Moment habe ich zum Hacken der blauen STM32-Pille gewechselt, aber ich möchte auf jeden Fall zu Arduino zurückkehren, sobald die Unterstützung für Avr in Rost bereit ist.

Wir @slowtec würden Rust auch gerne für unsere AVR-Projekte verwenden und natürlich würden wir einen Großteil unseres Produktionscodes als Open Source verwenden :)

Bump, würde gerne sehen, dass der Support offiziell wird. Werde versuchen, die Gabel für ein Projekt zu verwenden.

Update: Im Moment aktualisieren wir den Fork auf eine neuere Version von Rust (avr-rust/rust#137). Wir haben zwei Fehler gefunden, die wir gefunden haben.

LLVM-FEHLER: Während der Registerzuweisung sind keine Register mehr vorhanden

Dies wurde im LLVM-Trunk in llvm/ llvm-project@45eb4c7e55341c0b83a21dedecc092e273795eda behoben. Ich picke das jetzt in unseren LLVM-Fork heraus. Dieser Fehler war historisch gesehen der größte Schwachpunkt im Backend, der in den meisten zeigerlastigen Codes auftrat.

LLVM-FEHLER: Kann nicht auswählen: t2: i16 = addrspacecast[1 -> 0] undef:i16
t1: i16 = undef
In Funktion: _ZN4core3ptr87_$LT$impl$u20$core..fmt..Debug$u20$for$u20$unsafe$u20$fn$LP$A$RP$$u20$.$GT$$u20$Ret$GT $3fmt17h0fdf8ca7140def9b

Dieser ist schwieriger zu beheben. Es wird durch Rust verursacht, das Funktionszeiger auf Harvard-Architekturen falsch behandelt, wo es zwei separate Zeiger-Adressräume für den Zugriff auf den Hauptspeicher und den Programmspeicher gibt.

Die Erklärung liefert am besten @ecstatic-morse

Das zugrunde liegende Problem ist, dass *const T immer addrspace(0) hat. Ich denke, explizite Umwandlungen (ptr als *const T) sollten den Adressraum ihrer Eingabe hier beibehalten.

Der Fehler wird durch die std::fmt::Debug Implementierung für Funktionen und Funktionszeiger aufgedeckt. Rust gibt eine Zeigerdereferenzierung mit einem Zielzeigertyp von addrspace(0)* i16 , wobei LLVM-Routinen verwendet werden, die implizit einen Bitcast (iN -> iM Bits) oder einen Adressraum-Cast bei Bedarf einfügen. Im Fall von Funktionszeigern sollte Rust einen addrspace(1)* i16 Zeiger codieren, damit LLVM nicht ( addrspacecast ) PROGMEM-Zeiger auf RAM-Zeiger abbilden muss, eine unmögliche Aufgabe, da es keine Speicherzuordnung gibt und die Adressräume überlappen sich nicht.

Dieser Fehler ist der Hauptblocker.

Ich hoffe, dass Upstream-Rust vom LLVM-Master (AFAICT, es ist so ziemlich in der 8.0-Version) zieht, damit wir ein paar Rosinenpicks entfernen können.

Ich habe kürzlich die https://github.com/dylanmckay/avr-compiler-integration-tests/-Tests mit einem AVR-Emulator erfolgreich durchgeführt, was großartig ist, da es keine andere Testsuite gibt, die die von LLVM ausgespuckte AVR-Assembly tatsächlich ausführt. Ich habe einen GitLab-Runner eingerichtet, um Tests für jeden AVR-Rust-Commit auszuführen (über einen GitLab-Repository-Spiegel), aber es ist nicht sehr nützlich, da GitLab keine CI-Builds auf Pull-Requests unterstützt, da der eigentliche Code in a gehostet wird gegabeltes Repository.

Danke für das Update @dylanmckay. Wir alle wissen Ihre Mühe zu schätzen.

Wir haben jetzt den Fork auf die Rust-Basis rust-lang/ rust@fb7cca33f aktualisiert , das blink-Programm wird erfolgreich kompiliert.

Ist dieses Problem ins Stocken geraten?

Gibt es dazu Neuigkeiten? Ist die PR immer noch in Bezug auf das Adressraumproblem ins Stocken geraten?

Hey @dylanmckay , Entschuldigung für die

Hallo zusammen, hier ein paar Kommentare von mir

Rosinenpickerei-Fixes

Fast alle der erforderlichen Fixes, um libcore zum Laufen zu bringen, wurden zum LLVM-Master hochgeladen und existieren derzeit in der Fork rust-lang/llvm. Gestern habe ich eine PR gestartet, um die AVR-Gabel auf 1.39.0 (avr-rust/rust#155) zu aktualisieren, ich musste nur einen Fix auswählen, der noch nicht da war - avr-rust/ llvm@4350776601bc671e6e055bfbe32add34b70d2635.

libcore kann nicht ohne Modifikation kompiliert werden

Wir benötigen keinen benutzerdefinierten libcore-Fork mehr, um AVR zu verwenden. Es gibt derzeit nur eine Modifikation von libcore in der avr-rust Gabel - avr-rust/ rust@44240ac59c5949b8a9fd191f5cd666d0206fbe85 -

Wir sind auf xargo angewiesen, um AVR-Rust-Binärdateien zu kompilieren - dies wird mit den laufenden std-aware Cargo-Initiativen (einschließlich der Arbeitsgruppe) einfacher. Derzeit erfordert AVR ein kompiliertes Sysroot für jeden MCU-Typ - wir verwenden derzeit Xargo, um dies träge zu kompilieren, aber es wird viel nahtloser, wenn Cargo in der Lage ist, Core/std für die gewünschten Zielspezifikationen nativ zu kompilieren.

Alle Operationen auf Funktionszeigern außer 'Aufruf' greifen auf RAM zu, nicht auf Programmspeicher (avr-rust#68)

Dies wurde behoben.

32-Bit-Verschiebungen generieren Aufrufe an eine Compiler-RT-Routine, die nicht existiert (avr-llvm/llvm#163)

Dies ist immer noch ein schmerzhaftes Thema. Ich vermute, dass die beste Lösung darin besteht, benutzerdefinierten Reduzierungscode im LLVM AVR-Backend zu schreiben, der diese Verschiebungen auf reine Assemblierung verringert und jede ABI-Abhängigkeit von Compiler-rt oder libgcc entfernt. Ich bin mir nicht sicher, wie viel größer die generierte Codegröße sein könnte, es ist möglicherweise keine gute Idee.

Fragen vor dem Upstream

RFCs und instabile Aufrufkonventionen

Ich habe diesen Kommentar im Thread gepostet

Die Aufrufkonvention "avr-interrupt" wurde hinzugefügt. Dies ermöglicht extern "avr-interrupt" fn my_isr_handler() { .. }. Dies müsste wahrscheinlich den RFC-Prozess durchlaufen, um sich zu stabilisieren, aber ich könnte mich irren.

Können instabile Aufrufkonventionen hinzugefügt werden, ohne den RFC-Prozess zu durchlaufen?

Derzeit haben wir die "avr-interrupt" und "avr-non-blocking-interrupt" unter dem #![feature(abi_avr_interrupt)] Feature Gate. Könnten diese in Erwartung eines zukünftigen Stabilisierungs-RFC als instabile Anrufkonventionen vorgelagert werden?

Buildbots

Das Upstreaming eines LLVM-Back-Ends erfordert die Einrichtung eines dedizierten Buildbots, der Tests für dieses Back-End ausführt, und dessen Wartung. Ist das bei Rust so? Wie stellen wir sicher, dass die Testsuite bei jedem Push im AVR-Modus läuft? Was haben andere Back-Ends (wie WASM) gemacht?

Verteilung

Bedeutet "Merging the avr-rust Fork Upstream" einfach das Zusammenführen der beiden Forks zu einem, erfordert aber immer noch einen Build-from-Source? Vielleicht ist es möglich, dass ein Backend verteilt wird, aber nur nachts? Was haben die anderen Backends gemacht?

Abgesehen davon sind die avr-rost-spezifischen Patches sehr dünn, heutzutage ohne knorrige Hacks.

Das vollständige Patchset kann hier eingesehen werden https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support

Mein WIP 1.39.0 Rebase-Patchset (das größtenteils identisch ist) finden Sie hier https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support-1.39.0-4560ea788c . Diese soll in den nächsten Tagen zu avr-rust/master zusammengeführt werden.

Ich kann mir nichts Bestimmtes vorstellen, das dies blockiert - vielleicht ist es an der Zeit, Patches einzureichen und zu sehen, wie es läuft?

https://github.com/rust-lang/rust/issues/44036

Ich habe dieses Problem oben erwähnt, aber ich glaube nicht, dass es das Upstreaming des AVR-Backends blockiert. Wir sollten in der Lage sein, eine funktionierende, nützliche Version von rustc mit AVR ohne es zu landen. Ich bin mir sicher, dass es Workarounds und Hacks gibt, die wir tun können. Geräteerkennung in AVR-Kisten in der Zwischenzeit, nachdem das Backend hypothetisch zusammengeführt wurde und bevor eine offizielle Ziel-CPU-Abfrage-API im offiziellen Rust landet.

Er lebt! Danke für das Update @dylanmckay , spannende Fortschritte.

Tolle Arbeit @dylanmckay! Danke, dass Sie uns auf dem Laufenden halten.

Ein bisschen off-topic, aber: wäre rustc für avr in der Lage, FFI mit C-Bibliotheken zu tun?
Es gibt bereits viele ausgereifte Bibliotheken für avr, die jedoch in C/C++ geschrieben wurden.
Es wäre großartig, einige rostähnliche Wrapper für sie erstellen und in unseren Rost-Avr-Projekten wiederverwenden zu können.

Rust kann im Allgemeinen bereits FFI mit C ausführen.

Ja und das ist wirklich toll! Die Frage ist jedoch: Übersetzt es sich in Rost-Avr?

Solange die C ABI von LLVM für AVR mit der von gcc übereinstimmt, sollte es funktionieren

Können instabile Aufrufkonventionen hinzugefügt werden, ohne den RFC-Prozess zu durchlaufen?

Meine Stimme ist ja , da die Änderung zur Unterstützung der AVR-Anrufkonventionen im Grunde nur darin besteht, ihnen einen Namen zu geben und sie der LLVM-Nummer zuzuordnen. Es sind keine grundlegenden Codeänderungen erforderlich, da wir bereits Unterstützung für instabile Konventionen haben.

Das Upstreaming eines LLVM-Back-Ends erfordert die Einrichtung eines dedizierten Buildbots, der Tests für dieses Back-End ausführt, und dessen Wartung. Ist das bei Rust so? Wie stellen wir sicher, dass die Testsuite bei jedem Push im AVR-Modus läuft? Was haben andere Back-Ends (wie WASM) gemacht?

Das Stufensystem von Rust ist etwas locker definiert, aber ich denke, dass es richtig ist, den AVR-spezifischen Code zusammenzuführen . Dann wird AVR Tier 3 sein , was bedeutet, dass es nicht automatisch gebaut oder getestet wird,

Bedeutet "Merging the avr-rust Fork Upstream" einfach das Zusammenführen der beiden Forks zu einem, erfordert aber immer noch einen Build-from-Source?

Meines Wissens wäre es, den einen Commit als PR einzureichen. Unsere benutzerdefinierte Gabel würde effektiv sterben / zu einem Ort werden, um AVR-spezifische Details zu verfolgen, bis sie ein weit verbreiteteres Ziel wird.

Vielleicht ist es an der Zeit, Patches einzureichen

Ich glaube schon.

@edvorg sehr zum Thema IMO

Ein bisschen off-topic, aber: wäre rustc für avr in der Lage, FFI mit C-Bibliotheken zu tun?
Es gibt bereits viele ausgereifte Bibliotheken für avr, die jedoch in C/C++ geschrieben wurden.

Ja.. meistens. Die vom AVR-Backend implementierte AVR-Aufrufkonvention ist so konzipiert, dass sie mit den AVR-GCCs übereinstimmt ( hier dokumentiert). Es gibt einige Macken, aber der LLVM-Patch D68524, den ich überprüfen muss, sollte sie beheben.

Rust-Callsites werden immer in der Lage sein, Rust- oder avr-clang-kompilierte Funktionen korrekt aufzurufen (da avr-clang C die gleiche extern "C" Aufrufkonventionsimplementierung wie das Rust-Frontend verwendet) und die Interoperation mit AVR-GCC _sould_ funktionieren, insbesondere für einfache Funktionssignaturen, kann aber manchmal ersticken (weitere Details finden Sie in der Beschreibung von D68524).

Gibt es hierzu Neuigkeiten ?
Nur neugierig.

Eingereichte Anfrage, das LLVM AVR-Backend zu einem offiziellen Backend zu machen – https://reviews.llvm.org/D75099

@dylanmckay Wenn akzeptiert, was sind die verbleibenden Teile, um dieses Problem zu schließen?

@dylanmckay Wenn akzeptiert, was sind die verbleibenden Teile, um dieses Problem zu schließen?

Technisch funktioniert Rust sowohl mit offiziellen als auch mit experimentellen Backends. Ich habe #69478 für das Upstreaming des Großteils des Back-Ends erhoben.

Ich bin mir nicht sicher, ob die Zusammenführung von AVR als Tier-3-Ziel davon abhängt, dass AVR ein offizielles LLVM-Backend wird - Gedanken willkommen.

Wenn man darüber nachdenkt, kann die offizielle und experimentelle Unterscheidung von LLVM auf Rusts Stufensystem abgebildet werden, von denen Rust drei Stufen und LLVM zwei hat. Ein offizielles LLVM-Backend entspricht einer Mischung aus Tier 1 und 2 - im Grunde in Testsuiten und offiziellen Releases enthalten. Ein experimentelles LLVM-Backend ist, soweit ich das beurteilen kann, semantisch dasselbe wie ein Rust Tier 3-Backend; im Quellbaum enthalten, standardmäßig nicht in Releases enthalten, keine Einbeziehung in die standardmäßigen CI-Tests usw.

Dann werden die einzigen verbleibenden Teile zum Schließen dieses Problems diejenigen sein, die in der Codeüberprüfung von #69478 auftauchen.

tl;dr würde das AVR-Backend bei einer Zusammenführung zu einem Tier-3-Upstream-Ziel in rust-lang/rust#69478 werden, wodurch die Abzweigung beendet wird.

Der einzige Unterschied zwischen der avr-rust/rust-Fork und #69478 ist das target_cpu cfg-Flag, das in der AVR-Fork, aber nicht im Upstream vorhanden ist. Das habe ich bei der ersten PR weggelassen.

was sind die restlichen stücke

Ich bin mir ziemlich sicher, dass es immer noch eine Reihe von falschen Kompilierungen verschiedener Codetypen gibt, daher braucht es immer noch mehr Leute, um Dinge auszuprobieren und Fehler zu minimieren und sie zu beheben.

Aufgedampft zu werden wird die Messlatte senken, damit die Leute Dinge ausprobieren, da sie einfach jeden Abend einen normalen Rust bekommen können, anstatt die normalerweise veraltete Gabel zu kompilieren.

Funktioniert die AVR-Entwicklung mit der -Z build-std Funktion von Cargo, oder wird Xargo erforderlich, sobald es als Tier-3-Ziel vorgelagert ist? Verfügt das mit Rust gelieferte LLD über AVR-Unterstützung oder werden Gnu-Linker benötigt?

Funktioniert die AVR-Entwicklung mit der -Z build-std Funktion von Cargo oder wird xargo benötigt? Verfügt das mit Rust gelieferte LLD über AVR-Unterstützung oder werden Gnu-Linker benötigt?

Ich kann nicht sagen, dass diese nicht funktionieren werden, aber alles, was ich getan habe, hat Xargo- und GNU-Linker verwendet.

GNU-Linker sind unter Windows schwer einzurichten und xargo erfordert ein weiteres Tool zur Installation, deshalb frage ich.

Verfügt das mit Rust gelieferte LLD über AVR-Unterstützung oder werden Gnu-Linker benötigt?

LLD bietet nur eine sehr grundlegende Unterstützung für das Verknüpfen von AVR, es kann noch keine echten Programme verlinken. Daher wird avr-ld benötigt.

deshalb frage ich.

Machen Sie keinen Fehler, ich denke auch, dass das das richtige Endziel ist, es kann einfach nicht der aktuelle Zustand der Welt sein. Ehrlich gesagt würde ich gerne den Overhead niedriger und niedriger machen. Die Zusammenführung ist nur der erste Schritt dazu.

Das AVR-Backend wurde jetzt als offizielles LLVM-Ziel aktiviert :tada: LLVM-Master enthält jetzt standardmäßig AVR-Unterstützung. Die erste LLVM-Version, die standardmäßig AVR enthält, wird in etwa 6 Monaten LLVM 11 sein.

Schön! Danke für all die Mühe, die Sie sich hier machen.

Sehr cool!

Herzlichen Glückwunsch @dylanmckay zu dieser unglaublichen Leistung. Die Community dankt Ihnen für Ihre Arbeit.

Ich verfolge dieses Problem seit einiger Zeit und obwohl ich weiß, dass dies größtenteils nicht zum Thema gehört, interessiert es mich, was dies für den durchschnittlichen Benutzer bedeutet, der nicht aus der Quelle stammt ... Ist es ein komplizierter Prozess, eine Arduino Uno mit nativem Rust betriebsbereit damit? Das interessiert mich am meisten, da Rust genug Schutz bietet, den ich wahrscheinlich nicht annähernd so viele Oops-Momente verursachen kann xP

@ Jimmio92 Soweit ich das wenn alles gut geht.

_{Meine persönliche Erfahrung mit LLVM ist jedoch, dass es meistens einfach etwas auf Ihrem System nicht mag (zumindest auf macOS – es ist einfacher unter Linux und sicherlich nicht einmal davon träumen, dies unter Windows zu tun). so dass Sie unweigerlich Installationspfade und benutzerdefinierte Bibliotheken massieren, bis Sie entweder erfolgreich sind oder aufgeben.}

Was die (ausgezeichneten) Neuigkeiten oben bedeuten, ist nur Folgendes: Die Entwickler von LLVM zielen jetzt offiziell auf AVR ab/unterstützen es (?), und die nächste Version von LLVM wird AVR-Unterstützung beinhalten. Nichts spricht dafür, dass Rust nun auch AVR unterstützt oder kurzfristig unterstützen wird. Wenn Sie sich die Probleme und die obigen Kommentare ansehen, können Sie sehen, dass es eine Menge Arbeit erfordern wird, bis die AVR-Unterstützung mit einer standardmäßigen Rust-Toolchain "einfach funktioniert".

Gibt es einen Prozess/ein Beispiel, bei dem ich mir die Rosinenpickerei von AVR-Fixes vom LLVM-Master in die Rust LLVM-Fork ansehen könnte?

Verfolgt Rust auch den LLVM-Master? So wie es aussieht, verfolgt es die aktuelle Version sowie einige ausgewählte Fixes. Werden PRs zur Aktualisierung der LLVM-Version auf Master noch akzeptiert?

@dylanmckay

Verfolgt Rust auch den LLVM-Master?

Wie Sie bemerkt haben, verfolgt es jetzt Veröffentlichungen.

Werden PRs zur Aktualisierung der LLVM-Version auf Master noch akzeptiert?

Ich glaube nicht, aber cc @nikic

@dylanmckay es gibt eine Reihe von Fixes auf dem LLVM-Fork von Rust im Vergleich zum Release 10.0: https://github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05

Gibt es einen Prozess/ein Beispiel, bei dem ich mir die Rosinenpickerei von AVR-Fixes vom LLVM-Master in die Rust LLVM-Fork ansehen könnte?

Eine Anleitung gibt es hier: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

Verfolgt Rust auch den LLVM-Master? So wie es aussieht, verfolgt es die aktuelle Version sowie einige ausgewählte Fixes. Werden PRs zur Aktualisierung der LLVM-Version auf Master noch akzeptiert?

Rust verfolgt derzeit LLVM-Releases, da dies den Benutzern ermöglicht, auf einfache Weise sprachübergreifendes LTO mit einer entsprechenden Clang-Version durchzuführen. Die Standardantwort hier ist also wahrscheinlich "nein".

Allerdings gab es einige Diskussionen über die Aktualisierung auf den LLVM-Master, um Regressionen bei der Kompilierung von LLVM 10 zu mildern. Daran arbeite ich derzeit zu Evaluierungszwecken. Ich denke, es ist sicherer anzunehmen, dass dies nicht passieren wird, und Rosinenpicks gegen unsere LLVM 10-Fork einreichen (gibt es viele davon?)

Die Gabel wurde zusammengeführt! Ich werde heute Nachmittag ein richtiges Update schreiben

https://github.com/rust-lang/rust/pull/69478

Ich werde heute Nachmittag ein richtiges Update schreiben

Ich interessiere mich für besagtes Update. Wo wollen Sie es posten @dylanmckay (damit ich weiß, wo ich suchen muss :slightly_smiling_face:)?

Ich warte schon seit buchstäblich Jahren sehnsüchtig auf diese Ergänzung des Rust-Ökosystems! Meine naiven Versuche, dies auf Master zu verwenden, scheinen jedoch fehlerhaft zu sein.

Ich habe Master-Rost mit dem Standard ./x.py build , der als Toolchain master verknüpft ist, und dann versucht, das avr-rust/blink-Beispiel zu erstellen (nachdem src/main.rs aktualisiert wurde, um llvm_asm! ):

RUST_TARGET_PATH=`pwd`
XARGO_RUST_SRC=/home/nixpulvis/Projects/rust

rustup run master xargo build --target avr-atmega328p --release

Dies schlägt fehl mit:

error: no matching package named `core` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `sysroot v0.0.0 (/tmp/xargo.oXlxlujoXvXJ)`
error: `"cargo" "build" "--release" "--manifest-path" "/tmp/xargo.oXlxlujoXvXJ/Cargo.toml" "--target" "avr-atmega328p" "-p" "core"` failed with exit code: Some(101)
note: run with `RUST_BACKTRACE=1` for a backtrace

Ich gehe davon aus, dass noch eine Konfiguration erforderlich ist, die mir fehlt.

@nixpulvis siehe https://github.com/rust-lang/rust/issues/44052#issuecomment -591396417

Ich würde nicht erwarten, dass jetzt viel funktioniert, da libcore ein Teil von dem ist, was falsch kompiliert ist.

Die AVR-Rustc-Gabel wurde Upstream zusammengeführt.

Der Upstream-Fork ist generell noch nicht nutzbar. Es gibt ein paar Dinge, die zuerst passieren müssen.

AVR LLVM Upstream-Fixes, die Rust noch nicht hat, müssen ausgewählt werden

Um die Frage von @nikic zu beantworten,

Ich habe ein Skript verwendet, um _alle_ AVR-Commits vom LLVM-Upstream automatisch in einen lokalen Fork auszuwählen.
Dies ist ein großer Hammer, und es wird ausgewählte Fixes geben, die unnötig sind – es gibt Upstream-LLVM-Fixes, die in Upstream-Rust gezogen werden müssen, bevor das Backend verwendbar wird. Sie müssen herausgefiltert und nach Rust stromaufwärts gepflückt werden.

Kompilieren des AVR-LED-Blinkprogramms aus dem vorgelagerten Rust-Master-Zweig

Da die Upstream-Anstrengungen nun schon seit einigen Monaten andauern, ist die Downstream-Avr-Rost-Gabel
ist noch auf einer besonders alten Version von Rust. Seitdem hat es mindestens eine Änderung im Upstream-Rust gegeben, die eine Generalisierung erfordert, um AVR zu unterstützen, ohne dass LLVM-Assertion-Fehler auftreten. Ich habe Pull Request #73270 geöffnet, um das Problem zu beheben.

Ich bin mir nicht sicher, ob es andere Änderungen in Upstream Rust gegeben hat, die Änderungen für AVR erfordern - wahrscheinlich nicht.

Sobald ich das Blink-Programm zum Laufen gebracht habe, werde ich ein weiteres Update veröffentlichen, da zu diesem Zeitpunkt die Upstream-AVR-Unterstützung einsatzbereit sein sollte.

Wo soll die AVR-Kommunikation stattfinden/gepostet werden

@wezm Sie

Der AVR-Rust Gitterkanal ist die natürlichste Wahl, die es gibt. Ich mag die Idee einer Mailingliste (aber ich mag die Idee nicht, wenn möglich einen Mailserver zu hosten). Der Gitter-Kanal enthält Diskussionen, daher wäre vielleicht so etwas wie eine Mailingliste hilfreich.
Vielleicht wäre die Einrichtung eines Blogs gut, um Ankündigungen/Updates zu zentralisieren. Ich hätte gerne ein "offizielles Medium", damit Leute, die gelegentliche Updates wollen, nichts verpassen. Ich nehme an, ein Blog erfordert eine ständige Überprüfung auf neue Beiträge, während eine Mailingliste von Natur aus benachrichtigt
alle die es interessiert. Vorschläge willkommen.

Offene Fragen

• Sollten GitHub-Probleme auf dem avr-rust-Fork in das vorgelagerte Rust-Repository verschoben werden?
  ** Unabhängig davon sollten neue Probleme im Upstream-Repository angesprochen werden - der alte Issue Tracker muss heruntergefahren werden.
  
  
  
  • Wo sollte die Anleitung zum Kompilieren von Rust mit AVR live sein?
  
  

Das Wichtigste für die Zukunft (sprich: Prioritäten)

• Verpacken und Verteilen von AVR Rust-Binärdateien. Das Kompilieren von Rust kann dem Gelegenheitsbenutzer große Kopfschmerzen bereiten.
  Viele Distributionen scheinen von Zeit zu Zeit Probleme mit bestimmten Workflows zu haben. Mehrere OOM-Fehler wurden falsch gemeldet als
  Compiler-Fehler. Die Eintrittsbarriere ist unnötig hoch und muss gesenkt werden – einfach herunterladen und loslegen.
  Nachverfolgt von https://github.com/avr-rust/rust/issues/162
• Erstellen einer Liste von "unterstützten" oder zumindest getesteten Konfigurationen. Wir brauchen einen Tisch mit (rustc version, Xargo version) also
  dass Änderungen an privaten Rust-APIs, von denen Xargo abhängt, die AVR Rust-Toolchain beim Upgrade nicht unterbrechen.
  Xargo ist im Wartungsmodus - cargo-xbuild scheint ziemlich eingeschränkt zu sein (ich habe es vor ein paar Wochen ausprobiert, ich kann mich nicht an den Grund erinnern),
  Möglicherweise müssen wir Xargo verzweigen. Vielleicht ist es besser, die Werkzeuge direkt in Cargo hinzuzufügen (dafür gibt es ein Tracking-Problem).
• Einrichtung einer Art Homepage für das Projekt, inklusive Links zum Download
• Integrationstest (auf einem emulierten/simulierten AVR, bei jedem Commit)

Im Moment werde ich sicherstellen, dass Updates in dieser GitHub-Ausgabe erneut veröffentlicht werden, bis ein besseres Medium gefunden wird. Ich werde sie auch in Gitter posten.

Vielleicht wäre die Einrichtung eines Blogs gut, um Ankündigungen/Updates zu zentralisieren. Ich hätte gerne ein "offizielles Medium", damit Leute, die gelegentliche Updates wollen, nichts verpassen. Ich nehme an, ein Blog erfordert eine ständige Überprüfung auf neue Beiträge, während eine Mailingliste von Natur aus benachrichtigt
alle die es interessiert. Vorschläge willkommen.

Meine persönliche Vorliebe ist stark für einen Blog (mit RSS-Feed). Ich denke, Blogs werden in der Regel besser in den Suchmaschinenergebnissen angezeigt und lassen sich besser verlinken als Mailinglisten-Threads. Der RSS-Feed löst den Aspekt der Überprüfung/Benachrichtigung.

Ich bin mir nicht 100% sicher, ob es der beste Ort dafür ist, aber es gibt den Embedded WG-Blog. Könnte ein Kommunikationskanal mit geringem Aufwand sein.

https://rust-embedded.github.io/blog/

Vielleicht auch ein Twitter-Account? Es kann verwendet werden, um neue Blog-Posts zu teilen (um auf dem Laufenden zu bleiben).

Ich denke, die Embedded-Arbeitsgruppe hilft hier gerne weiter. Wir haben einen Twitter-Account @rustembedded und können sicherlich auch AVR-bezogene Neuigkeiten in den Newsletter aufnehmen.

Ich habe vor einiger Zeit auch das Label O-AVR , also kannst du den Rust Issue Tracker auch für AVR-spezifische Probleme verwenden (aber bedenken Sie, dass 1,5k Leute das Repo beobachten). Darüber hinaus möchten Sie sich vielleicht auf dem rust-lang Zulip koordinieren, da dort die meisten Rust-Teams ansässig sind. Wir sind auch dabei, "Zielgruppen" aufzubauen, die sich auf bestimmte Rust-Ziele (zB Windows oder Arm) konzentrieren, AVR könnte auch dafür gut geeignet sein. Wenden Sie sich hierfür gerne an Zulip.

Aktualisieren.

Es bleiben noch zwei Dinge, bevor libcore für AVR auf einem Stock rust-lang/master-Zweig kompiliert werden kann:

1. Es gibt eine Pull-Anfrage, die eine Reihe von "Adressraum-Cast ungültig"-Fehlern auf AVR behebt, die sich darauf beziehen, wie Funktionszeiger für Harvard-Architekturen als addrspace(1) verglichen mit Von-Neumann-Zielen, die mit Rusts aktuellem Standard in Ordnung sind von addrspace(0) . rust-lang/rust#73270 - es befindet sich derzeit in der Codeüberprüfung

~2. Es gibt einen weiteren Fehler, der das blink Beispiel daran hindert, zu funktionieren - avr-rust/rust#92. Es gibt einen noch nicht hochgestreamten Patch, der das Problem beheben wird – https://reviews.llvm.org/D68524. Dies wird vorgelagert und dann sehr bald in Rusts LLVM-Fork ausgewählt, sobald es die Unit- und Integrationstests bestanden hat. ~ Es wurde in Upstream-LLVM zusammengeführt

Sobald diese beiden Dinge erledigt sind, kann das vorgelagerte Rust-AVR-Ziel AVR-Code auf die gleiche Ebene wie die aktuelle avr-rust/rust-Fork kompilieren, und wir können dann mit der Aktualisierung des blink Beispiels beginnen , arduino Kiste, Dokumentation, Anleitungen, für den Upstream-Zweig. Dann sollte der Upstream-Zweig für den experimentellen Einsatz bereit sein.

Noch eine TODO:

1. ~Füge AVR-Installationen für die neue Inline-Assembly-Syntax in Upstream Rust hinzu~
   
   
   
   • ~Sobald die neue Inline-Assembly-Syntax unterstützt wird, muss die Arduino-Kiste aktualisiert werden, um sie zu verwenden
     
     Sobald die Arduino-Kiste aktualisiert wurde, aktualisieren Sie die Blink-Kiste auf die neue Version.~ Wir können das alte Makro über llvm_asm! vorerst verwenden, da es in nightly noch existiert.
   
   
2. Rosinenpick AVR-Korrektheitspatches (meistens Aykes) vom LLVM-Master zum Upstream-Rust-LLVM-Fork (EDIT: PR: https://github.com/rust-lang/llvm-project/pull/66)

Hier die Filiale mit allem: https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. Dieser Zweig reicht aus, um libcore zu kompilieren.

Es wird aus Upstream rust-lang/master , enthält aber auch den noch nicht vorgeschalteten LLVM-Patch D68524 , den noch nicht zusammengeführten Rust PR rust-lang/rust#73270 und 46 AVR-bezogene Commits von Upstream-LLVM, die automatisch über Skript (LLVM-Zweig: https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate). Beachten Sie, dass nicht alle 46 erforderlich sind, die endgültige Liste wird kleiner sein.

Update : Es wurde eine Pull-Anfrage geöffnet, die alle Upstream-LLVM-Fixes enthält.

Hier ist eine vollständige Liste der verbleibenden Arbeiten, bevor das LED-Blinkprogramm kompiliert und erfolgreich ausgeführt werden kann.

Verbleibende Arbeit

• [x] Land Rust PR rost-lang/rust#73270 . Dieser Pull-Request behebt eine Reihe von "address space cast invalid"-Fehlern auf AVR, die sich darauf beziehen, wie Funktionszeiger für Harvard-Architekturen als addrspace(1) markiert werden müssen, im Vergleich zu Von-Neumann-Zielen, die mit Rusts aktueller Standardeinstellung von addrspace(0) in Ordnung sind. . Es befindet sich derzeit in der Codeüberprüfung.
• [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Dies zieht alle erforderlichen AVR-Fixes von Upstream-LLVM in Rusts LLVM-Fork. Am Ende gab es ~17~ 16 LLVM-Fixes, die ausgewählt werden mussten.
• [x] Land Rust PR rust-lang/rust#73658, das die Version des LLVM-Submoduls aktualisiert . Die Rust-Compiler- Dokumentation enthält Anweisungen dazu. Es befindet sich derzeit in der Codeüberprüfung .
• [x] Land Rost PR ~rust-lang/rust#74625~ rost-lang/rust#74631 . In 79a42e37084d0 begann Rust, das Argument --eh-frame-hdr bedingungslos an den Linker zu übergeben. Der AVR-GCC-Linker unterstützt dieses Flag nicht und daher wird für AVR ein Sonderfall hinzugefügt, um die Weitergabe zu vermeiden, ähnlich den bestehenden Ausschlüssen für Windows. Solaris und UEFI.

Vielleicht ist es besser, die Werkzeuge direkt in Cargo hinzuzufügen (dafür gibt es ein Tracking-Problem).

Ich gehe davon aus, dass dies das richtige Problem ist: rust-lang/cargo#4959.

cargo build -Z build-std=core hat für meine AVR-Beispielfälle gut funktioniert.

@shepmaster das scheint mich sowieso näher zu bringen, danke! Ich scheine jetzt einfach beim Bitcast-Zeug hängen zu bleiben, also warte ich, bis das zusammengeführt wird (da ich anscheinend eine Datei vermisse, die zum Erstellen des PR und IDK erforderlich ist, was ich tue).

Bei der Verwendung von -Z build-std=core ich ein Zieltripel angeben, also habe ich rustc +master --print target-list | grep avr und avr-unknown-unknown . Aber das archivierte Problem avr-llvm/llvm#35 scheint es so zu machen, als ob das Triple tatsächlich avr-atmel-none (was für mich sowieso mehr Sinn macht). Muss hier etwas aktualisiert werden oder übersehe ich etwas?

avr-unknown-unknown ist richtig.

Offene Fragen

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

Ich denke, das ist auf der Benutzerseite nicht so wichtig. Dies war leicht zu finden durch ddg und/oder this-week-in-rust.
Was auch immer es den Entwicklern leichter macht.

Offene Fragen

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

Ich denke, das ist auf der Benutzerseite nicht so wichtig. Dies war leicht zu finden durch ddg und/oder this-week-in-rust.
Was auch immer es den Entwicklern leichter macht.

Ich denke, die Anweisungen zum Kompilieren von Rust mit AVR sollten irgendwie in https://docs.rust-embedded.org/ sein.

Okay, Aktualisierungszeit.

Alle erforderlichen Patches für AVR sind im aktuellen Rust-Nightly-Compiler ab dem heutigen Nighty rustc 1.47.0-nightly (0820e54a8 2020-07-23) . Der Rust Nightly Compiler kann jetzt ohne Modifikation das LED-Blink-Beispiel erfolgreich kompilieren und eine AVR ELF-Datei generieren.

• Neue, zentrale Projekt-Landingpage erstellt unter https://avr-rust.com/
• Ein neues Buch - The AVR-Rust Guidebook wurde erstellt, gehostet auf GitHub-Seiten unter book.avr-rust.com.
• Das Repository avr-rust/rust fork ist veraltet. Das Repository wurde noch nicht archiviert, da vorhandene Probleme migriert werden sollten, bevor sie dauerhaft gesperrt und geschlossen werden.
• Xargo wird nicht mehr benötigt - das -Z build-std Flag im Upstream Rust ersetzt die Notwendigkeit dafür auf AVR. Eine Frachtgabel wird nicht mehr benötigt - Upstream-Ladung reicht aus.

Der Rust Nightly Compiler kann jetzt als empfohlener Kanal für Rust mit AVR-Unterstützung angesehen werden.

Ich schließe dieses Thema jetzt - wir haben es geschafft!

Schritte zum Melden von Fehlern finden Sie im AVR Guidebook .

Das AVR-Handbuch und das Blink-Beispiel unter https://github.com/avr-rust/blink sind die besten Ressourcen, um mit der Verwendung des Targets zu beginnen.

Ein tiefes, tiefes Dankeschön an alle, die das Projekt durch diese Upstreaming-Bemühungen diskutiert und unterstützt haben - es wird sehr geschätzt.

FLOSSE

Wow wow wow.

Danke an alle, die dazu beigetragen haben – auf diesen Tag freue ich mich schon ewig!

Dylan McKay vor der Portierung von Rost zu Avr

Und danach

Vielen Dank für all die harte Arbeit, Mann! :-) Ruh dich gut aus!