Rust: RFC : Fusion de la fourche avr-rust en amont

Créé le 23 août 2017  ·  89Commentaires  ·  Source: rust-lang/rust

Bonjour à tous,

J'aimerais connaître les opinions générales sur la fusion de la fourche avr-rust dans Rust proprement dit.

La fourche elle-même est devenue beaucoup plus stable avec moins de bugs ces derniers mois. Il a également commencé à attirer un certain nombre de personnes intéressées à l'utiliser.

Vous pouvez trouver l'un des projets les plus intéressants en utilisant avr-rust sur GitHub .

Bloqueurs

LLVM 5.0

~Rust est actuellement sur LLVM 4.0, qui contient un backend AVR fonctionnel, mais il y a eu de nombreuses corrections de bugs depuis lors. Nous devrons attendre que LLVM 5.0 soit pris en charge (presque terminé : #43370) avant d'obtenir une version du backend AVR qui corrige quelques bogues importants.~

Ce n'est plus un bloqueur. Upstream Rust est à LLVM 6.0 à partir du 2018-02-20.

Des questions

Corrections sélectives

Si la prise en charge AVR était intégrée à la ligne principale, nous aurions besoin de pouvoir sélectionner les correctifs dans le fork LLVM de Rust. Je n'imagine pas que ce serait vraiment un problème, car nous avons déjà sélectionné un certain nombre de correctifs importants.

Toutes les corrections de bogues sélectionnées dans le référentiel avr-rust ont déjà été transférées en amont dans le tronc LLVM, ce qui continuerait d'être le cas si nous fusionnions le fork, car je ne suis pas un fan du fork LLVM qui s'éloigne trop du tronc.

La sélection est nécessaire en raison du cycle de publication de 6 mois de LLVM.

Problèmes actuels dans le backend AVR

Il n'y a pas de bogues connus dans le référentiel avr-rust/rust - tous les bogues connus sont des problèmes dans le backend AVR LLVM ; voici quelques-unes des plus intéressantes / percutantes.

libcore ne peut pas être compilé sans modification

Il y a un jalon mis en place pour suivre quels bogues doivent être corrigés afin d'obtenir libcore compilation réussie de

Cela n'a pas été un gros problème pour les utilisateurs jusqu'à présent, car libcore à la volée si nécessaire, et nous pouvons remplacer libcore dans Xargo.toml .

Je ne sais pas ce que l'équipe Rust pense de la fusion d'une cible qui ne peut pas utiliser le libcore d'origine.

Toutes les opérations sur les pointeurs de fonction autres que la RAM d'accès « appel », pas la mémoire du programme (avr-rust/rust#68)

C'est un symptôme du fait qu'AVR est le tout premier backend LLVM dans l'arborescence pour une architecture Harvard. LLVM suppose actuellement que toutes les fonctions résident dans "l'espace d'adressage générique", qui correspond à la RAM. Pour cette raison, si vous essayez de charger/stocker via un pointeur de fonction, il accédera à la RAM au lieu de la mémoire du programme.

La bonne nouvelle est que j'ai des correctifs LLVM en amont en attente pour le corriger ( D37052 , D37053 , D37054 , D37057 ).

Les décalages de 32 bits génèrent des appels à une routine compiler-rt qui n'existe pas (avr-llvm/llvm#163)

Parce qu'il n'y a pas beaucoup (le cas échéant) de cibles qui ne prennent pas en charge les décalages 32 bits en natif, libgcc et compiler-rt n'ont pas de versions 32 bits de la routine de décalage, même si LLVM reste génère joyeusement un appel à elle.

Cela provoque une erreur de symbole indéfinie lors de la liaison. Cela ne se produira que si vous écrivez du code ou utilisez du code qui effectue des décalages de 32 bits, car l'éditeur de liens est assez efficace pour supprimer tout le code mort.

Notez qu'un utilisateur a rencontré le bug de décalage manquant en raison de la compilation en mode de publication, qui a promu une multiplication en un décalage en tant qu'"optimisation".

Modifications réelles à fusionner

Vous pouvez trouver toutes les différences spécifiques à l'AVR en consultant cette différence .

Notez que plus de la moitié de ce diff n'est que la configuration README et Travis CI - le code réel en amont est très petit ; juste du code de colle pour activer le backend AVR et une spécification cible.

Ce diff désactive également sous condition des parties de libcore pour AVR - ces correctifs ne seraient pas en amont et ne sont pas strictement requis car les utilisateurs en aval peuvent utiliser Xargo pour compiler un libcore minifié pour AVR).

Liens

AVR-rouille sur Gitter
AVR-Rust sur GitHub

C-feature-request O-AVR T-core WG-embedded

Commentaire le plus utile

D'accord, l'heure de la mise à jour.

Tous les correctifs requis pour AVR existent dans le compilateur de nuit Rust actuel à partir de la nuit d'aujourd'hui rustc 1.47.0-nightly (0820e54a8 2020-07-23) . Le compilateur Rust nightly, sans modification, peut maintenant compiler l'exemple de clignotement de LED avec succès et générer un fichier AVR ELF.

  • Nouvelle page de destination de projet centralisée créée à l' adresse https://avr-rust.com/
  • Un nouveau livre - Le guide AVR-Rust a été créé, hébergé sur les pages GitHub à book.avr-rust.com.
  • Le référentiel avr-rust/rust fork a été déprécié. Le référentiel n'a pas encore été archivé car il existe des problèmes existants qui doivent être migrés avant qu'ils ne soient définitivement verrouillés et fermés.
  • Xargo n'est plus requis - le drapeau -Z build-std dans Rust en amont en remplace le besoin sur AVR. Une fourche à cargaison n'est plus nécessaire - la cargaison en amont fera l'affaire.

Le compilateur Rust nightly peut désormais être considéré comme le canal recommandé pour Rust avec prise en charge AVR.

Je ferme ce problème maintenant - nous l'avons fait !

Les étapes pour signaler les bogues peuvent être trouvées dans le guide AVR .

Le guide AVR et l'exemple de clignotement sur https://github.com/avr-rust/blink sont les meilleures ressources pour commencer à utiliser la cible.

Un grand merci à tous ceux qui ont discuté et soutenu le projet à travers cet effort en amont - c'est très apprécié.

AILETTE

Tous les 89 commentaires

+1 ! Avr rust intégré au compilateur lui-même serait super utile. Il est presque exempt de bugs maintenant.

Pas complètement exempt de bugs :)

Je mettrai à jour la description pour inclure des informations sur l'état du backend par rapport aux bogues

Presque si 😄. Juste un couple pour aller

En général, nous sommes plutôt favorables aux plateformes en amont dans rust-lang/rust tant qu'elles ne nous imposent pas une charge de maintenance ! Quelques réflexions spécifiques à partir de ce que vous pensez :

  • La sélection des commits LLVM de temps en temps est tout à fait acceptable, je pense que vous avez déjà suivi le processus plusieurs fois :)
  • Les intrinsèques manquants dans compiler-rt nous conviennent, vous avez également la possibilité de les implémenter dans Rust via le projet compiler-builtins.
  • Le patch que vous avez semble assez bon, même si je pense que nous voudrions travailler davantage sur les divers #[cfg] dans libcore. Ces éléments sont-ils laissés de côté en raison de "bugs dans LLVM" ou parce qu'ils ne sont fondamentalement pas pris en charge sur AVR ? Le premier serait mieux fait en "réparant LLVM" d'une manière ou d'une autre, tandis que le dernier rend les choses plus délicates.

En général, nous avons actuellement toutes les plates-formes avec la même interface uniforme de libcore/libstd, mais il n'est pas clair que cela restera vrai car nous continuons à prendre plus de plates-formes.

Le patch que vous avez semble assez bon, même si je pense que nous voudrions travailler davantage sur les différents #[cfg] de libcore. Ces éléments sont-ils laissés de côté en raison de "bugs dans LLVM" ou parce qu'ils ne sont fondamentalement pas pris en charge sur AVR ?

C'est à cause de bogues dans LLVM.

La seule question qui me vient à l'esprit concerne la prise en charge des types i128 / u128 - je pense que pour l'AVR, ceux-ci ne sont pas vraiment utiles. La prise en charge de i128 dans libcore est actuellement commentée à cause d'un bogue, mais il peut y avoir d'autres bogues non découverts car ce n'est pas un chemin de code bien testé, et exerce vraiment l'allocateur de registre en tant qu'AVR uniquement a 32 octets de registres à usage général.

Il est toujours assez probable que nous puissions faire fonctionner i128 sur AVR, je ne connais pas trop les problèmes spécifiques qu'il déclenche dans le backend.

Je pense que la meilleure voie à suivre serait de proposer le patch pour de vrai une fois que libcore _fait_ compiler sans modification, ou du moins sans beaucoup.

Je pense que la meilleure voie à suivre serait de proposer le correctif pour de vrai une fois que libcore se compilera sans modification, ou du moins sans beaucoup.

Cela me semble raisonnable !

La seule question qui me vient à l'esprit concerne la prise en charge des types i128/u128 - je pense que pour l'AVR, ceux-ci ne sont pas vraiment utiles.

Ma principale crainte de ne pas prendre en charge i128 sur AVR est que cela aura un effet dissuasif sur l'adoption d'entiers 128 bits pour des raisons de compatibilité avec AVR ou d'autres plates-formes embarquées. Par exemple, s'il existe une bibliothèque qui utilise des entiers de 128 bits, les utilisateurs d'AVR qui voudront l'utiliser signaleront des problèmes pour abandonner l'utilisation. Cela pourrait rendre les entiers 128 bits non "sûrs" à utiliser dans le code Rust qui s'efforce d'être portable, ce que je n'aimerais pas qu'il se produise.

un effet dissuasif sur l'adoption d'entiers 128 bits par souci de compatibilité avec l'AVR ou d'autres plates-formes embarquées

Je ne pense pas que ce soit un gros problème ici. Les petits périphériques embarqués ont déjà des limitations géantes (pas de stdin / stdout, généralement pas d'allocateur, etc.) qui rendent très difficile de simplement déposer dans une bibliothèque arbitraire. J'ai récemment appris que le double AVR GCC est en fait un alias pour float ! Je ne sais pas si nous allons garder cette étrangeté ou non, mais cela affecterait les caisses bien plus que i128 .

Je pense que nous aurons toujours des fonctionnalités spéciales qui seront utilisées pour créer une caisse adaptée à l'embarqué, tout comme nous le faisons pour le non-std.

pas de stdin / stdout, généralement pas d'allocateur, etc.

Vous décrivez l'écosystème #![no_std] . Il existe des bibliothèques qui ciblent cet écosystème. Et la règle générale pour cet écosystème est de prendre libcore comme une donnée, ce qui inclut également i128 . Chaque cible qui ne prend pas en charge i128 a un effet paralysant plus important à l'intérieur de cet écosystème, car la "part de marché" d'une cible intégrée est plus importante dans le sous-ensemble de l'ensemble de l'écosystème Rust où la famille x86 n'est pas un acteur très pertinent .

Je ne sais pas si nous allons conserver cette étrangeté ou non, mais cela affecterait bien plus les caisses que i128.

Intéressant! Je suis d'accord que si nous utilisions un alias f64 à f32 (ou ne le fournissions pas), cela affecterait davantage l'écosystème. Cependant, si nous pouvons viser la cohérence, pourquoi ne le ferions-nous pas ? Il nous est certainement possible d'implémenter i128 .

Il nous est tout à fait possible d'implémenter i128.

Absolument, et je me rends compte que je n'ai pas clairement indiqué que je pense que nous utilise réellement un i128 sur un AVR va être dans un monde de douleur.

Cependant, si nous pouvons viser la cohérence, pourquoi ne le ferions-nous pas ?

Cohérence avec quoi , telle est la question. Cohérence avec GCC ( f64 == f32 ) ou avec toutes les autres cibles Rust ( f64 != f32 ) ?

Vous décrivez l'écosystème #![no_std].

Oui, c'est pourquoi j'ai dit « des fonctionnalités spéciales qui sont utilisées pour rendre une caisse adaptée à l'intégration, tout comme nous le faisons pour le non-std ». ??

Un problème plus important qui me trotte dans la tête depuis que nous avons initialement mis au point le correctif 16 bits usize est que, fondamentalement, les programmeurs Rust et Rust ont tendance à supposer que usize est le "natif" taille d'un registre. AFAIK, cela est vrai pour toutes les autres plates-formes cibles Rust, mais pas pour AVR.

La cohérence avec quoi, telle est la question. Cohérence avec GCC (f64 == f32) ou avec toutes les autres cibles Rust (f64 != f32) ?

Le nom f64 indique littéralement qu'il a 64 bits. Si vous ne respectez pas le nom, il perd tout son sens, tout comme en C.

Bons points ici, je peux voir l'inquiétude autour des entiers 128 bits. Je pense vraiment qu'ils devraient être soutenus, même si nous ne devrions pas encourager leur utilisation. Je détesterais voir des caisses devoir ajouter des indicateurs de fonctionnalité pour des choses comme les impls de trait sur les types i128 . Cela ne devrait pas vraiment être un problème car tous les éléments inutilisés de l'i128 doivent être supprimés par l'éditeur de liens.

Le problème f32/64 est intéressant. Ma principale préoccupation concernant la création de f64 en 64 bits est que cela signifie que C FFI pourrait être très cassant. Si les développeurs ne savent pas qu'AVR-GCC utilise des doubles 32 bits, alors les appels via FFI pourraient lire la mémoire non initialisée ou une erreur de segmentation.

J'imagine que nous pourrions résoudre ce problème plus ou moins en s'attendant à ce que les utilisateurs utilisent à la place des types de la caisse libc . Nous pourrions ajouter une fonctionnalité spécifique à l'AVR pour définir c_double sur f32 . Je pense que nous pouvons raisonnablement nous attendre à ce que les gens utilisent la caisse libc dans leurs fixations FFI.

Quelque chose à retenir pour la fusion, besoin de mettre à jour le type c_int utilisé dans la signature main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Edit : a ouvert un problème pour cela car il affecte également MSP430 : https://github.com/rust-lang/rust/issues/44934

utilisé dans la signature main()

@matico Peut-être que je viens de faire les choses d'une manière étrange, mais aucun de mes codes n'a utilisé les main de Rust :

#[no_mangle]
pub extern fn main() {

Plus important encore , nous ne pouvons pas revenir vraiment parce qu'il n'y a rien à y retourner. Chaque programme doit s'exécuter indéfiniment.

@matico Nous devrons certainement encore modifier la libc pour que les types correspondent à GCC pour AVR

Oh, absolument, je ne sais pas du tout que main aura un impact sur nous.

@shepmaster Même sur les plates-formes non intégrées, la taille de argc dans main n'a pas d'importance étant donné que nous nous sommes trompés tout ce temps et que personne ne l'a remarqué, sauf lors de l'inspection de l'IR. Il peut y avoir un RTOS qui utilise un point d'entrée main() standard pour ses processus ? Quoi qu'il en soit, c'est assez facile à réparer.

Il aurait probablement fallu autant de temps pour soumettre un correctif que pour le taper, maintenant que j'y pense 😄

Est-ce juste les problèmes de libcore qui empêchent cette fusion ? Juste pour que nous sachions où concentrer nos efforts.

Les seuls problèmes que j'ai rencontrés avec libcore sont des erreurs d'éditeur de liens étranges causées par je ne sais quoi et aussi des erreurs de décalage de bits 32 bits (manquant intrinsèque je pense). Je ne sais pas si ceux-ci bloquent la fusion cependant.

chocol4te : Est-ce juste les problèmes de libcore qui empêchent cette fusion ? Juste pour que nous sachions où concentrer nos efforts.

Oui - tout le travail requis ici doit être effectué dans LLVM .

Restioson : Les seuls problèmes que j'ai rencontrés avec libcore sont des erreurs d'éditeur de liens étranges causées par je ne sais quoi et aussi des erreurs de décalage de bits 32 bits (manquant intrinsèque je pense).

C'est parce que tout le code qui fait le starter backend AVR est commenté :)

Restioson : Je ne sais pas si ceux-ci bloquent la fusion.

Pas directement, mais ce serait bien d'avoir corrigé avant que le backend ne soit fusionné. Il y a quelques bugs vraiment ennuyeux comme celui-ci que nous devrions envisager de corriger avant de fusionner, mais ils ne le retardent pas nécessairement.

@dylanmckay LLVM6 a été fusionné https://github.com/rust-lang/rust/pull/47828 - qu'est-ce que cela signifie pour cette RFC ?

@kellerkindt, tous les problèmes répertoriés dans "Problèmes actuels dans le backend AVR" sont toujours vrais. Il est probable que le HEAD actuel d'avr-rust puisse être rebasé et que le code intéressant spécifique à Rust soit fusionné, mais le code ne fonctionne toujours pas.

Je suis personnellement toujours en faveur de

Je pense que la meilleure voie à suivre serait de proposer le correctif pour de vrai une fois que libcore se compilera sans modification, ou du moins sans beaucoup.

Bien qu'il soit agréable d'éviter un rebasage supplémentaire.

Je me demande l'état actuel de Rust sur AVR, maintenant que nous sommes six mois plus tard en développement. Je dirige un petit groupe de projets Arduino dans ma ville et j'adorerais pouvoir utiliser Rust à la place.

Alors, bonne nouvelle !

Je pense que la meilleure voie à suivre serait de proposer le correctif pour de vrai une fois que libcore se compilera sans modification, ou du moins sans beaucoup.

C'est maintenant le cas !

Le fork avr-rust actuel ne contient aucune modification de libcore .

Les modifications requises pour prendre en charge l'AVR du stock Rus sont :

  • Les fonctions d'initialisation du backend AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} sont déclarées et appelées.
  • Une spécification de cible avr minimale de base avr-unknown-unknown a été ajoutée. Cela modélise le comportement par défaut d'avr-gcc de construire pour le plus petit dénominateur commun, sauf indication contraire. Contrairement à avr-gcc qui prend explicitement en charge l'argument -mmcu=<avr mcu name> , aucun argument de ligne de commande spécifique à AVR n'a été ajouté pour AVR. Cela signifie qu'un fichier JSON de spécification de cible personnalisée doit être écrit pour chaque projet. C'est le cas pour de nombreux projets intégrés Rust.
  • Dans le fork, le backend AVR LLVM est toujours compilé et lié dans le checkout Rust par défaut et ajouté au fichier config.toml.example . L'AVR doit-il être inclus par défaut dans Rust en amont, ou doit-il également être activé ?
  • Logique spécifique AVR ajoutée au compilateur si nécessaire pour toutes les nouvelles cibles
  • La convention d'appel "avr-interrupt" a été ajoutée. Cela permet extern "avr-interrupt" fn my_isr_handler() { .. } . Cela devrait probablement passer par le processus RFC pour se stabiliser, mais je peux me tromper.
  • Prise en charge d'une compilation conditionnelle sur CPU, à la #[cfg(target_cpu = "...")] a été ajoutée. La mise en œuvre peut être trouvée ici . L'implémentation de ceci est indépendante de la cible, et cela fonctionne donc pour la compilation conditionnelle basée sur le CPU pour d'autres architectures également, telles que ARM. Cela permet à la caisse ruduino d'inclure de manière conditionnelle un module spécifique au périphérique qui expose tous les E/S, registres et modules pris en charge dans le silicium. Cela doit absolument passer par le processus RFC avant l'amont.

Il est probablement temps que j'envoie une RFC à LLVM-dev concernant la promotion du backend au statut non expérimental.

Vous pouvez voir l'ensemble complet des changements de Rust en amont vers avr-rust ici .

Il y a encore quelques correctifs LLVM des deux derniers mois que nous avons sélectionnés pour le moment, mais les efforts en amont de Rust pour séparer la version emscripten de LLVM de la version de LLVM utilisée pour toutes les autres cibles l'ont rendu vraiment facile à apporter ces changements depuis le rust-lang/llvm , car il est désormais mis à jour régulièrement en amont.

Les <4 correctifs LLVM triés sur le volet que nous avons sont actuellement en cours de révision dans le LLVM en amont, et donc une fois qu'un examinateur aura trouvé suffisamment de temps, ces correctifs flotteront automatiquement dans Rust en amont. Upstream Rust a également des correctifs spécifiques à la cible Rust, et donc les correctifs LLVM sélectionnés ne sont probablement pas vraiment un bloqueur pour la fusion d'avr-rust en amont

Une mise à jour sur l'état de Rust sur AVR ?

Intéressé aussi à savoir ! Pour l'instant, je suis passé au piratage sur la pilule bleue STM32, mais je voudrais certainement revenir à arduino une fois que le support pour avr en rouille sera prêt.

Nous @slowtec aimerions également utiliser Rust pour nos projets AVR et bien sûr, nous

Bump, aimerait voir le soutien officialisé. Je vais essayer d'utiliser le fork pour un projet.

Mise à jour : pour le moment, nous mettons à niveau le fork vers une version plus récente de Rust (avr-rust/rust#137). Il y a deux bugs que nous avons trouvés que nous avons touchés.

ERREUR LLVM : manque de registres lors de l'allocation des registres

Cela a été corrigé dans le tronc LLVM dans llvm/ llvm-project@45eb4c7e55341c0b83a21dedecc092e273795eda. Je sélectionne cela dans notre fourchette LLVM maintenant. Ce bogue était historiquement le plus gros problème dans le backend, apparaissant dans la plupart des codes lourds en pointeurs.

ERREUR LLVM : Impossible de sélectionner : t2 : i16 = addrspacecast[1 -> 0] undef:i16
t1 : i16 = undef
En fonction : _ZN4core3ptr87_$LT$impl$u20$core..fmt..Debug$u20$for$u20$unsafe$u20$fn$LP$A$RP$$u20$.$GT$$u20$Ret$GT $3fmt17h0fdf8ca7140def9b

Celui-ci est plus difficile à réparer. Cela est dû à une mauvaise gestion des pointeurs de fonction de Rust sur les architectures Harvard où il existe deux espaces d'adressage de pointeur distincts pour accéder à la mémoire principale et à la mémoire du programme.

L'explication est mieux faite par @ecstatic-morse

Le problème sous-jacent est que *const T a toujours addrspace(0). Je pense que les transtypages explicites (ptr as *const T) devraient préserver l'espace d'adressage de leur entrée ici.

Le bogue est exposé par l'implémentation std::fmt::Debug pour les fonctions et les pointeurs de fonction. Rust émet un déréférencement de pointeur avec un type de pointeur cible de addrspace(0)* i16 , en utilisant des routines LLVM qui inséreront implicitement un bitcast (iN -> iM bits) ou un cast d'espace d'adressage si nécessaire. Dans le cas des pointeurs de fonction, Rust devrait coder un pointeur addrspace(1)* i16 , afin que LLVM n'ait pas à mapper ( addrspacecast ) les pointeurs PROGMEM aux pointeurs RAM une tâche impossible car il n'y a pas de mappage de mémoire et les espaces d'adressage ne se chevauchent pas.

Ce bug est le principal bloqueur.

J'espère que Rust extrait en amont du maître LLVM (AFAICT, c'est à peu près à la version 8.0) afin que nous puissions supprimer un tas de choix.

J'ai récemment obtenu les tests https://github.com/dylanmckay/avr-compiler-integration-tests/ en utilisant un émulateur AVR, ce qui est génial car il n'y a pas d'autre suite de tests qui exécute réellement l'assemblage AVR craché par LLVM. J'ai configuré un exécuteur GitLab pour exécuter des tests pour chaque commit AVR-Rust (via un miroir de référentiel GitLab), mais ce n'est pas très utile car GitLab ne prend pas en charge les builds CI sur les demandes d'extraction, car le code réel est hébergé dans un référentiel fourchu.

Merci pour la mise à jour @dylanmckay. Nous apprécions tous l'effort que vous avez consacré à cela.

Nous avons maintenant mis à niveau le fork sur la base Rust rust-lang/ rust@fb7cca33f , le programme blink compile avec succès.

Ce problème est-il bloqué ?

Avez-vous des mises à jour à ce sujet? Le PR est-il toujours bloqué sur le problème de l'espace d'adressage ?

@dylanmckay , désolé d'avoir buggé avec ça. Y a-t-il une mise à jour sur le problème ?

Bonjour à tous, voici quelques commentaires de ma part

Corrections sélectives

Presque tous les correctifs requis pour que libcore fonctionnent ont été transférés en amont vers le maître LLVM et existent actuellement dans le fork rust-lang/llvm. Hier, j'ai commencé un PR pour mettre à jour la fourche AVR à 1.39.0 (avr-rust/rust#155), je n'ai eu qu'à choisir un correctif qui n'était pas déjà là - avr-rust/ llvm@4350776601bc671e6e055bfbe32add34b70d2635.

libcore ne peut pas être compilé sans modification

Nous n'avons plus besoin d'un fork libcore personnalisé pour utiliser AVR. Il n'y a actuellement qu'une seule modification de libcore dans la fourche avr-rust - avr-rust/ rust@44240ac59c5949b8a9fd191f5cd666d0206fbe85 - réécrire un

Nous dépendons de xargo pour compiler les binaires AVR-Rust - cela deviendra plus facile avec les initiatives Cargo compatibles avec std (y compris le groupe de travail). Actuellement, AVR nécessite une racine système compilée pour chaque type de MCU - nous utilisons Xargo pour le moment pour compiler cela paresseusement, mais ce sera beaucoup plus transparent lorsque Cargo sera capable de compiler nativement core/std pour les spécifications cibles souhaitées.

Toutes les opérations sur les pointeurs de fonction autres que la RAM d'accès « appel », pas la mémoire du programme (avr-rust#68)

Cela a été corrigé.

Les décalages 32 bits génèrent des appels à une routine compiler-rt qui n'existe pas (avr-llvm/llvm#163)

C'est toujours un problème douloureux. Je soupçonne que la meilleure solution sera d'écrire un code de réduction personnalisé dans le backend LLVM AVR qui réduit ces changements à l'assemblage pur, en supprimant toute dépendance ABI sur compiler-rt ou libgcc. Je ne sais pas à quel point la taille du code généré pourrait être plus grande, ce n'est peut-être pas une bonne idée.

Questions avant l'amont

RFC et conventions d'appel instables

J'ai posté ce commentaire sur le fil

La convention d'appel "avr-interrupt" a été ajoutée. Cela permet à l'externe "avr-interrupt" fn my_isr_handler() { .. }. Cela devrait probablement passer par le processus RFC pour se stabiliser, mais je peux me tromper.

Des conventions d'appel instables peuvent-elles être ajoutées sans passer par le processus RFC ?

Actuellement, nous avons les "avr-interrupt" et "avr-non-blocking-interrupt" sous la porte de fonctionnalité #![feature(abi_avr_interrupt)] . Celles-ci pourraient-elles être mises en amont en tant que conventions d'appel instables, en attendant une future RFC de stabilisation ?

Buildbots

La mise en amont d'un backend LLVM nécessite la configuration d'un buildbot dédié qui exécute des tests pour ce backend et sa maintenance. Est-ce le cas avec Rust ? Comment s'assurer que la suite de tests s'exécute en mode AVR à chaque poussée ? Que faisaient les autres backends (comme WASM) ?

Distribution

« Fusionner la fourche avr-rust en amont » signifie-t-il simplement fusionner les deux fourches en une seule, mais nécessitant toujours une génération à partir de la source ? Peut-être est-il possible de distribuer un backend, mais uniquement la nuit ? Qu'ont fait les autres backends ?

En dehors de cela, les correctifs spécifiques à avr-rust sont très minces, sans aucun piratage noueux de nos jours.

Le patchset complet peut être vu ici https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support

Mon ensemble de correctifs de rebase WIP 1.39.0 (qui est pour la plupart identique) peut être trouvé ici https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support-1.39.0-4560ea788c . Cela devrait être fusionné avec avr-rust/master dans les prochains jours.

Je ne vois rien de spécifique qui bloque cela - il est peut-être temps de soumettre des correctifs et de voir comment cela se passe ?

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

J'ai mentionné ce problème ci-dessus, mais je ne pense pas que cela bloque la mise en amont du backend AVR. Nous devrions pouvoir obtenir une version fonctionnelle et utile de rustc avec AVR sans lui. Je suis sûr qu'il existe des solutions de contournement et des hacks que nous pouvons faire. détection de périphérique dans les caisses AVR entre-temps après que le backend a été hypothétiquement fusionné et avant qu'une API officielle d'interrogation du processeur cible n'arrive dans Rust officiel.

Il habite! Merci pour la mise à jour @dylanmckay , des progrès passionnants.

Super travail @dylanmckay ! Merci de nous tenir informés.

Un peu hors sujet, mais : est-ce que rustc for avr serait capable de faire des FFI avec des librairies C ?
Il existe de nombreuses bibliothèques matures déjà disponibles pour avr mais écrites en C/C++.
Ce serait formidable de pouvoir leur créer des emballages de style rouille et de les réutiliser dans nos projets Rust Avr.

Rust peut déjà faire FFI avec C en général.

Oui et c'est vraiment super ! La question est cependant : cela se traduit-il par rouille-avr ?

Tant que l'ABI C de LLVM pour AVR correspond à celle de gcc, cela devrait fonctionner

Des conventions d'appel instables peuvent-elles être ajoutées sans passer par le processus RFC ?

Mon vote est oui , car le changement pour prendre en charge les conventions d'appel AVR consiste essentiellement à leur donner un nom et à les mapper sur le numéro LLVM. Il n'y a pas de changements de code fondamentaux nécessaires car nous avons déjà un support pour les conventions instables.

La mise en amont d'un backend LLVM nécessite la configuration d'un buildbot dédié qui exécute des tests pour ce backend et sa maintenance. Est-ce le cas avec Rust ? Comment s'assurer que la suite de tests s'exécute en mode AVR à chaque poussée ? Que faisaient les autres backends (comme WASM) ?

Le système de niveaux de Rust est un peu vaguement défini, mais je pense que la bonne chose à faire est de fusionner le code spécifique à AVR . Ensuite, l'AVR sera de niveau 3 , ce qui signifie qu'il n'est pas automatiquement construit ou testé, simplement suspendu dans le code. À tout le moins, cela signifie que ces fichiers seront tenus à jour avec les modifications du compilateur.

« Fusionner la fourche avr-rust en amont » signifie-t-il simplement fusionner les deux fourches en une seule, mais nécessitant toujours une génération à partir de la source ?

À ma connaissance, ce serait de soumettre le seul commit en tant que PR. Notre fourche personnalisée mourrait / deviendrait un endroit pour suivre les détails spécifiques à l'AVR jusqu'à ce qu'elle devienne une cible plus largement utilisée.

il est peut-être temps de soumettre des correctifs

Je le pense.

@edvorg très sur le sujet IMO

Un peu hors sujet, mais : est-ce que rustc for avr serait capable de faire des FFI avec des librairies C ?
Il existe de nombreuses bibliothèques matures déjà disponibles pour avr mais écrites en C/C++.

Oui.. la plupart du temps. La convention d'appel AVR implémentée par le backend AVR est conçue pour correspondre à celle d'AVR-GCC (documentée ici ). Il y a quelques bizarreries, mais le correctif LLVM D68524 que je dois revoir devrait les corriger.

Les sites d'appels Rust seront toujours en mesure d'invoquer correctement les fonctions compilées Rust ou avr-clang (car avr-clang C utilise la même implémentation de convention d'appel extern "C" que l'interface Rust), et l'interopérabilité avec AVR-GCC _devrait_ fonctionner, surtout pour les signatures de fonctions simples, mais cela peut parfois étouffer (voir la description du D68524 pour plus de détails).

Une mise à jour pour ceci ?
Juste curieux.

Demande soumise pour faire du backend LLVM AVR un backend officiel - https://reviews.llvm.org/D75099

@dylanmckay Si elle est acceptée, quelles sont les pièces restantes pour clore ce problème ?

@dylanmckay Si elle est acceptée, quelles sont les pièces restantes pour clore ce problème ?

Techniquement, Rust fonctionnera avec les backends officiels et expérimentaux. J'ai soulevé #69478 pour la mise en amont de la majeure partie du backend.

Je ne sais pas si la fusion d'AVR en tant que cible de niveau 3 suppose qu'AVR devienne un backend officiel de LLVM - pensées bienvenues.

En y réfléchissant, la distinction officielle contre expérimentale de LLVM peut être mappée sur le système de niveaux de Rust, dont Rust a trois niveaux et LLVM en a deux. Un backend officiel LLVM correspond à un mélange de niveaux 1 et 2 - essentiellement, inclus dans les suites de tests et les versions officielles. Autant que je sache, un backend expérimental LLVM est sémantiquement identique à un backend Rust Tier 3 ; inclus dans l'arborescence des sources, non inclus dans les versions par défaut, non inclus dans les tests CI par défaut, etc.

Ensuite, je suppose que les seuls éléments restants pour clore ce problème seront ceux qui apparaîtront dans la revue de code de #69478.

tl;dr le backend AVR deviendrait une cible en amont de niveau 3 dans rust-lang/rust#69478 s'il était fusionné, tuant ainsi le fork.

La seule différence entre le fork avr-rust/rust et #69478 est le drapeau target_cpu cfg qui existe dans le fork AVR mais pas en amont. J'ai laissé cela de côté du PR initial.

quelles sont les pièces restantes

Je suis presque sûr qu'il y a encore un certain nombre d'erreurs de compilation de divers types de code, il faut donc encore plus de personnes pour essayer des choses, minimiser les bogues et les corriger.

Le fait de se faire remonter la vapeur abaissera la barre pour que les gens essaient des choses, car ils peuvent simplement obtenir un Rust régulier tous les soirs au lieu de compiler le fork généralement obsolète.

Une fois qu'il sera en amont en tant que cible de niveau 3, le développement de l'AVR fonctionnera-t-il avec la fonctionnalité -Z build-std cargo, ou nécessitera-t-il xargo ? Le LLD livré avec Rust prend-il en charge AVR, ou des linkers gnu seront-ils nécessaires ?

Le développement de l'AVR fonctionnera-t-il avec la fonctionnalité -Z build-std cargo, ou nécessitera-t-il xargo ? Le LLD livré avec Rust prend-il en charge AVR, ou des linkers gnu seront-ils nécessaires ?

Je ne peux pas dire que cela ne fonctionnera

Les linkers GNU sont difficiles à installer sous Windows et xargo nécessite un outil supplémentaire pour être installé, c'est pourquoi je pose la question.

Le LLD livré avec Rust prend-il en charge AVR, ou des linkers gnu seront-ils nécessaires ?

LLD n'a qu'un support très basique pour lier AVR, il ne peut pas encore lier de vrais programmes. Par conséquent, avr-ld sera requis.

c'est pourquoi je demande.

Ne vous y trompez pas, je pense aussi que c'est le bon objectif final, ce n'est peut-être pas l'état actuel du monde. Honnêtement, je serais heureux de faire baisser les frais généraux de plus en plus bas. La fusionner n'est que la première étape vers cela.

Le backend AVR est désormais activé en tant que cible LLVM officielle :tada: Le maître LLVM contient désormais la prise en charge AVR par défaut. La première version de LLVM à inclure AVR par défaut sera LLVM 11 dans environ 6 mois.

Agréable! Merci pour tous les efforts que vous mettez là-dedans.

Très cool!

Félicitations @dylanmckay pour cette incroyable réalisation. La communauté vous remercie pour votre travail sur ce sujet.

Je suis ce problème depuis un certain temps maintenant et bien que je sache que c'est principalement hors sujet, je suis intéressé par ce que cela signifie pour l'utilisateur moyen qui ne provient pas de la source... Est-ce un processus compliqué d'obtenir un Arduino Uno opérationnel avec Rust natif en utilisant ceci? Cela m'intéresse le plus car Rust a suffisamment de protections, je ne peux probablement pas causer autant de moments oops xP

@ Jimmio92 D'après ce que je peux dire, oui. Comme dans "oui, c'est compliqué". Ou du moins long et fastidieux, même s'il n'est pas particulièrement compliqué, puisqu'il faut quand même construire ce fork personnalisé du compilateur Rust à partir des sources, ce qui implique également de construire LLVM à partir des sources. Cela prend généralement quelques heures, si tout se passe bien.

Mon expérience personnelle avec LLVM est, cependant, que le plus souvent, il n'aime tout simplement pas quelque chose sur votre système (du moins certainement sur macOS - c'est plus facile sur Linux et certainement ne rêvez même pas de le faire sur Windows), vous finissez donc inévitablement par masser les chemins d'installation et les bibliothèques personnalisées jusqu'à ce que vous réussissiez ou abandonniez.

Ce que signifient les (excellentes) nouvelles ci-dessus, c'est seulement ceci : les développeurs de LLVM ciblent/supportent désormais officiellement AVR (?), et la prochaine version de LLVM inclura le support AVR. Rien ne dit que Rust prend désormais en charge ou prendra également en charge AVR à court terme. Si vous regardez les problèmes et les commentaires ci-dessus, vous pouvez voir qu'il faudra beaucoup de travail jusqu'à ce que le support AVR "fonctionne" avec une chaîne d'outils Rust d'origine.

Existe-t-il un processus/un exemple que je pourrais examiner pour sélectionner les correctifs AVR du maître LLVM dans le fork Rust LLVM ?

De plus, Rust suit-il toujours le maître LLVM ? À première vue, il suit la version actuelle ainsi que quelques correctifs sélectionnés. Les PR pour mettre à jour la version LLVM vers master sont-ils toujours acceptés ?

@dylanmckay

De plus, Rust suit-il toujours le maître LLVM ?

Comme vous l'avez remarqué, il suit les sorties maintenant.

Les PR pour mettre à jour la version LLVM vers master sont-ils toujours acceptés ?

Je ne pense pas mais cc @nikic

Existe-t-il un processus/un exemple que je pourrais examiner pour sélectionner les correctifs AVR du maître LLVM dans le fork Rust LLVM ?

Des instructions sont disponibles ici : https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

De plus, Rust suit-il toujours le maître LLVM ? À première vue, il suit la version actuelle ainsi que quelques correctifs sélectionnés. Les PR pour mettre à jour la version LLVM vers master sont-ils toujours acceptés ?

Rust suit actuellement les versions de LLVM, car cela permet aux utilisateurs d'effectuer facilement des LTO multilingues avec une version de clang correspondante. La réponse par défaut ici est donc probablement "non".

Cela dit, il y a eu des discussions sur la mise à jour vers le maître LLVM pour atténuer les régressions au moment de la compilation de LLVM 10. J'y travaille actuellement à des fins d'évaluation. Je pense qu'il est plus sûr de supposer que cela n'arrivera pas et de soumettre des sélections contre notre fourche LLVM 10 (y en a-t-il beaucoup ?)

La fourchette a été fusionnée ! Je vais écrire une mise à jour appropriée cet après-midi

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

Je vais écrire une mise à jour appropriée cet après-midi

Je suis intéressé par ladite mise à jour. Où comptez-vous le poster @dylanmckay (pour que je sache où chercher :slightly_smiling_face:) ?

J'attends avec impatience cet ajout à l'écosystème Rust depuis des années maintenant ! Mes tentatives naïves d'utiliser ceci sur le maître semblent cependant imparfaites.

J'ai construit master rust avec le ./x.py build standard, lié en tant que chaîne d'outils master , puis j'ai essayé de construire l'exemple avr-rust/blink (après avoir mis src/main.rs jour llvm_asm! ):

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

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

Cela échoue avec :

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

Je suppose qu'il y a encore une configuration requise qui me manque.

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

Je ne m'attendrais pas à ce que grand-chose fonctionne maintenant, car libcore fait partie de ce qui est mal compilé.

La fourche AVR rustc a été fusionnée en amont.

La fourche amont n'est pas encore utilisable en général. Il y a quelques choses qui doivent arriver en premier.

Corrections en amont d'AVR LLVM que Rust n'a pas encore besoin d'être sélectionnées

Pour répondre à la question de @nikic , il y a un maximum de 20 commits LLVM qui doivent être sélectionnés.

J'ai utilisé un script pour sélectionner automatiquement _tous_ les commits AVR de LLVM en amont dans un fork local.
C'est un gros marteau et il y aura des correctifs triés sur le volet qui ne sont pas nécessaires - il existe des correctifs LLVM en amont qui doivent être transférés vers Rust en amont avant que le backend ne devienne utilisable. ils devront être filtrés et triés sur le volet jusqu'à Rust en amont.

Compilation du programme de clignotement de la LED AVR à partir de la branche maître Rust en amont

Comme l'effort amont se poursuit depuis quelques mois, la fourche aval avr-rust
est toujours sur une version particulièrement ancienne de Rust. Depuis lors, il y a eu au moins un changement dans Rust en amont qui nécessite une généralisation pour prendre en charge AVR sans rencontrer d'erreurs d'assertion LLVM. J'ai ouvert la pull request #73270 pour le corriger.

Je ne sais pas s'il y a eu d'autres changements dans Rust en amont qui nécessitent des changements pour AVR - probablement pas.

Une fois que j'aurai fait fonctionner le programme blink, je publierai une autre mise à jour car à ce stade, le support AVR en amont devrait être prêt à être utilisé/expérimenté.

Où la communication AVR doit-elle avoir lieu/être publiée

@wezm, vous soulevez un bon point - il n'y a pas nécessairement de canal de communication "béni" pour les mises à jour. Ce ticket a bien servi, mais il sera forcément fermé prochainement.

Le canal AVR-Rust Gitter est le choix existant le plus naturel. J'aime l'idée d'une liste de diffusion (mais je n'aime pas l'idée d'héberger un serveur de messagerie si possible). Le canal Gitter contient des discussions, donc peut-être que quelque chose comme une liste de diffusion serait utile.
Peut-être que la mise en place d'un blog serait bien pour centraliser les annonces/mises à jour. J'aimerais avoir un "support officiel" pour que les gens qui veulent des mises à jour occasionnelles ne manquent pas. Je suppose qu'un blog nécessite une vérification constante des nouveaux articles, alors qu'une liste de diffusion notifie intrinsèquement
tous ceux qui sont intéressés. Suggestions bienvenues.

Questions ouvertes

  • Les problèmes GitHub sur le fork avr-rust doivent-ils être déplacés vers le référentiel Rust en amont ?
    ** Quoi qu'il en soit, de nouveaux problèmes devraient être soulevés sur le référentiel en amont - l'ancien outil de suivi des problèmes devra être arrêté.

    • Où les instructions de compilation de Rust avec AVR devraient-elles être diffusées ?

Les choses les plus importantes pour l'avenir (lire : priorités)

  • Emballage et distribution des binaires AVR Rust. Compiler Rust peut être un gros casse-tête pour l'utilisateur occasionnel,
    de nombreuses distributions semblent avoir des problèmes de temps en temps dans certains flux de travail. Plusieurs erreurs OOM signalées à tort comme
    bogues du compilateur. La barrière à l'entrée est inutilement élevée et doit être plus basse - il suffit de télécharger et de partir.
    Suivi par https://github.com/avr-rust/rust/issues/162
  • Construire une liste de configurations « prises en charge » ou au moins testées. Nous avons besoin d'une table de (rustc version, Xargo version) donc
    les modifications apportées aux API Rust privées dont dépend Xargo ne brisent pas la chaîne d'outils AVR Rust lors de la mise à niveau.
    Xargo est en mode maintenance - cargo-xbuild semble assez limité (je l'ai essayé il y a quelques semaines, je ne me souviens plus de la raison),
    nous devrons peut-être forker Xargo. Peut-être mieux d'ajouter l'outillage directement dans Cargo (il y a un problème de suivi pour cela).
  • Mettre en place une sorte de page d'accueil pour le projet, y compris des liens pour télécharger
  • Test d'intégration (sur un AVR émulé/simulé, à chaque commit)

Pour le moment, je m'assurerai de republier les mises à jour dans ce problème GitHub, jusqu'à ce qu'un meilleur support soit trouvé. Je les posterai aussi dans Gitter.

Peut-être que la mise en place d'un blog serait bien pour centraliser les annonces/mises à jour. J'aimerais avoir un "support officiel" pour que les gens qui veulent des mises à jour occasionnelles ne manquent pas. Je suppose qu'un blog nécessite une vérification constante des nouveaux articles, alors qu'une liste de diffusion notifie intrinsèquement
tous ceux qui sont intéressés. Suggestions bienvenues.

Ma préférence personnelle est fortement en faveur d'un blog (avec un flux RSS). Je pense que les blogs apparaissent généralement mieux dans les résultats des moteurs de recherche et sont plus agréables à lier que les fils de liste de diffusion. Le flux RSS résout l'aspect vérification/notification.

Je ne suis pas sûr à 100% que ce soit le meilleur endroit pour ça, mais il y a le blog Embedded WG. Peut-être un canal de communication à faible effort.

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

Peut-être aussi un compte Twitter ? Il peut être utilisé pour partager de nouveaux articles de blog (pour rester à jour).

Je pense que le groupe de travail intégré serait heureux d'aider ici. Nous avons un compte Twitter @rustembedded et pouvons certainement aussi inclure des nouvelles liées à l'AVR dans la newsletter.

J'ai également créé le label O-AVR quelque temps, alors n'hésitez pas à utiliser le suivi des problèmes Rust pour les problèmes spécifiques à AVR (mais sachez qu'il y a 1,5k personnes qui regardent le repo). En plus de cela, vous voudrez peut-être vous coordonner sur le rust-lang Zulip, car c'est là que résident la plupart des équipes Rust. Nous sommes également en train de développer des "groupes cibles" qui se concentrent sur des cibles Rust spécifiques (par exemple, Windows ou Arm), AVR pourrait également être un bon choix pour cela. N'hésitez pas à contacter Zulip pour cela.

Mettre à jour.

Il reste deux choses avant que libcore puisse être compilé pour AVR sur une branche stock rust-lang/master :

  1. Il y a une pull request qui corrige une série de bogues "address space cast invalid" sur AVR, expliquant comment les pointeurs de fonction pour les architectures Harvard doivent être étiquetés comme addrspace(1) par rapport aux cibles Von-Neumann qui sont bien avec la valeur par défaut actuelle de Rust de addrspace(0) . rust-lang/rust#73270 - il est actuellement en révision de code.

~2. Il y a un autre bogue bloquant le fonctionnement blink l'exemple https://reviews.llvm.org/D68524. Cela sera mis en amont puis sélectionné dans le fork LLVM de Rust très bientôt une fois qu'il aura réussi les tests unitaires et d'intégration. ~ il a été fusionné dans le LLVM en amont

Une fois ces deux choses faites, la cible Rust AVR en amont pourra compiler le code AVR au même niveau que le fork avr-rust/rust actuel, et nous pourrons alors commencer le processus de mise à jour de l'exemple blink , arduino caisse, documentation, guides, pour la branche amont. Ensuite, la branche amont devrait être prête pour une utilisation expérimentale.

Encore une tâche à faire :

  1. ~Ajouter la plomberie AVR pour la nouvelle syntaxe d'assemblage en ligne dans Rust en amont~

    • ~ Une fois la nouvelle syntaxe d'assemblage en ligne prise en charge, la caisse Arduino doit être mise à jour pour l'utiliser

      une fois la caisse Arduino mise à jour, mettez à jour la caisse clignotante vers la nouvelle version. ~ Nous pouvons utiliser l'ancienne macro via llvm_asm! pour l'instant car elle existe toujours dans la nuit.

  2. Correctifs AVR choisis par Cherry (principalement ceux d'Ayke) du maître LLVM au fork Rust LLVM en amont (EDIT : PR : https://github.com/rust-lang/llvm-project/pull/66)

Voici la branche avec tout : https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. Cette branche est suffisante pour compiler libcore.

Il est construit à partir de rust-lang/master amont mais comprend également le correctif LLVM pas encore en amont D68524 , Rust PR pas encore fusionné rust-lang/rust#73270 et 46 commits liés à AVR de LLVM en amont automatiquement sélectionnés via script (branche LLVM : https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate). Notez que tous les 46 ne sont pas obligatoires, la liste finale sera plus petite.

Mise à jour : ouverture d'une demande d'extraction qui inclut tous les correctifs LLVM en amont.

Voici une liste exhaustive du travail restant avant que le programme de clignotement des LED puisse être compilé et exécuté avec succès.

Le travail restant

  • [x] Land Rust PR rust-lang/rust#73270 . Cette pull request corrige une série de bogues "address space cast invalid" sur AVR, expliquant comment les pointeurs de fonction pour les architectures Harvard doivent être étiquetés comme addrspace (1) par rapport aux cibles Von-Neumann qui conviennent à la valeur par défaut actuelle de Rust d'addrspace (0) . Il est actuellement en révision de code.
  • [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Cela extrait tous les correctifs AVR requis du LLVM en amont dans le fork LLVM de Rust. En fin de compte, il y avait ~ 17 ~ 16 correctifs LLVM qui devaient être triés sur le volet.
  • [x] Land Rust PR rust-lang/rust#73658 qui met à jour la version du sous-module LLVM . La documentation du compilateur Rust Il est actuellement en révision de code .
  • [x] Land Rust PR ~rust-lang/rust#74625~ rust-lang/rust#74631 . En 79a42e37084d0, Rust a commencé à transmettre inconditionnellement l'argument --eh-frame-hdr à l'éditeur de liens. L'éditeur de liens AVR-GCC ne prend pas en charge cet indicateur et donc un cas spécial pour éviter de le transmettre est ajouté pour AVR, similaire aux exclusions existantes pour Windows. Solaris et UEFI.

Peut-être mieux d'ajouter l'outillage directement dans Cargo (il y a un problème de suivi pour cela).

Je suppose que c'est le bon problème : rust-lang/cargo#4959.

cargo build -Z build-std=core a bien fonctionné pour mes exemples de cas AVR.

@shepmaster qui semble me rapprocher de toute façon, merci ! Je semble juste être bloqué sur les trucs bitcast maintenant, donc j'attendrai que cela soit fusionné (puisqu'il me manque un fichier nécessaire pour construire le PR, et IDK ce que je fais).

Dans le processus d'utilisation de -Z build-std=core j'avais besoin de fournir un triple cible, j'ai donc exécuté rustc +master --print target-list | grep avr , et j'ai trouvé avr-unknown-unknown . Mais le problème archivé avr-llvm/llvm#35 semble donner l'impression que le triple devrait en fait être avr-atmel-none (ce qui me semble plus logique de toute façon). Est-ce que quelque chose doit être mis à jour ici, ou est-ce que j'ai raté quelque chose ?

avr-unknown-unknown est correct.

Questions ouvertes

* 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?

Je ne pense pas que cela ait trop d'importance du côté de l'utilisateur. C'était assez facile à trouver via ddg et/ou this-week-in-rust.
Tout ce qui facilite les choses pour les développeurs.

Questions ouvertes

* 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?

Je ne pense pas que cela ait trop d'importance du côté de l'utilisateur. C'était assez facile à trouver via ddg et/ou this-week-in-rust.
Tout ce qui facilite les choses pour les développeurs.

Je pense que les instructions pour compiler Rust avec AVR devraient être en quelque sorte dans https://docs.rust-embedded.org/

D'accord, l'heure de la mise à jour.

Tous les correctifs requis pour AVR existent dans le compilateur de nuit Rust actuel à partir de la nuit d'aujourd'hui rustc 1.47.0-nightly (0820e54a8 2020-07-23) . Le compilateur Rust nightly, sans modification, peut maintenant compiler l'exemple de clignotement de LED avec succès et générer un fichier AVR ELF.

  • Nouvelle page de destination de projet centralisée créée à l' adresse https://avr-rust.com/
  • Un nouveau livre - Le guide AVR-Rust a été créé, hébergé sur les pages GitHub à book.avr-rust.com.
  • Le référentiel avr-rust/rust fork a été déprécié. Le référentiel n'a pas encore été archivé car il existe des problèmes existants qui doivent être migrés avant qu'ils ne soient définitivement verrouillés et fermés.
  • Xargo n'est plus requis - le drapeau -Z build-std dans Rust en amont en remplace le besoin sur AVR. Une fourche à cargaison n'est plus nécessaire - la cargaison en amont fera l'affaire.

Le compilateur Rust nightly peut désormais être considéré comme le canal recommandé pour Rust avec prise en charge AVR.

Je ferme ce problème maintenant - nous l'avons fait !

Les étapes pour signaler les bogues peuvent être trouvées dans le guide AVR .

Le guide AVR et l'exemple de clignotement sur https://github.com/avr-rust/blink sont les meilleures ressources pour commencer à utiliser la cible.

Un grand merci à tous ceux qui ont discuté et soutenu le projet à travers cet effort en amont - c'est très apprécié.

AILETTE

Waouh Waouh Waouh.

Merci à tous ceux qui ont contribué à cela – j'attends ce jour avec impatience depuis toujours !

Dylan McKay avant de porter rust sur avr

image
Et après
image

Merci pour tout le travail acharné mec! :-) Reposez-vous bien !

Cette page vous a été utile?
0 / 5 - 0 notes