皆さんこんにちは、
avr-rustフォークをRust本体にマージすることについての一般的な意見を知りたいです。
フォーク自体は、ここ数ヶ月でバグが少なくなり、はるかに安定しています。 また、それを使用することに興味を持っている多くの人々を引き付け始めました。
GitHubでavr-rustを使用したより興味深いプロジェクトの1つを見つけることができます。
〜Rustは現在LLVM 4.0にあり、動作するAVRバックエンドが含まれていますが、それ以来、多くのバグ修正が行われています。 いくつかの重要なバグが修正されたバージョンのAVRバックエンドを入手する前に、LLVM 5.0がサポートされるのを待つ必要があります(ほぼ完成:#43370)。
これはもはやブロッカーではありません。 Upstream Rustは、2018-02-20の時点でLLVM6.0になっています。
AVRサポートがメインラインに組み込まれている場合、RustのLLVMフォークにパッチをチェリーピックできる必要があります。 すでにいくつかの重要な修正をそこに選んでいるので、これがそれほど問題になるとは思いません。
avr-rustリポジトリにチェリーピックされたすべてのバグ修正は、すでにLLVMトランクにアップストリームされています。これは、トランクから離れすぎているLLVMフォークのファンではないため、フォークをマージした場合も引き続き当てはまります。
LLVMのリリースサイクルは6か月であるため、チェリーピッキングが必要です。
avr-rust / rustリポジトリには既知のバグはありません。既知のバグはすべて
libcore
は変更せずにコンパイルすることはできませんlibcore
を変更せずに正常にコンパイルするには、どのバグを修正する必要があるかを追跡するためのマイルストーンが設定されています。
xargoは必要に応じてオンザフライでlibcore
を透過的にコンパイルし、 Xargo.toml
libcoreをオーバーライドできるため、これまでのところユーザーにとってはそれほど問題にはなりません
Rustチームが、ストックlibcoreを使用できないターゲットをマージすることについてどう考えているかわかりません。
これは、ハーバードアーキテクチャの最初のツリー内LLVMバックエンドであるAVRの兆候です。 LLVMは現在、すべての関数がRAMに対応する「汎用アドレス空間」にあると想定しています。 このため、関数ポインタを介してロード/ストアしようとすると、プログラムメモリではなくRAMにアクセスします。
良いニュースは、それを修正するための保留中のアップストリームLLVMパッチ( D37052 、 D37053 、 D37054 、 D37057 )があることです。
compiler-rt
ルーチンへの呼び出しを生成します(avr-llvm / llvm#163)32ビットシフトをネイティブにサポートしないターゲットは(あるとしても)多くないため、LLVMはまだ32ビットバージョンのシフトルーチンを持っていませんが、 libgcc
とcompiler-rt
は32ビットバージョンのシフトルーチンがありません。喜んでそれへの呼び出しを生成します。
これにより、リンク中に未定義のシンボルエラーが発生します。 これは、実際にコードを記述した場合、または32ビットシフトを実行するコードを使用した場合にのみ発生します。これは、リンカーがすべてのデッドコードを削除するのに非常に優れているためです。
リリースモードでコンパイルしたために、1人のユーザーがシフトの欠落のバグに遭遇したことに注意してください。これにより、「最適化」としてシフトへの乗算が促進されました。
この差分を見ると、AVR固有のすべての違いを見つけることができます。
その差分の半分以上がREADMEとTravisCIの構成であることに注意してください。アップストリームされる実際のコードは非常に小さいです。 AVRバックエンドとターゲット仕様を有効にするためのいくつかのグルーコード。
この差分はまた、AVRのlibcore
一部を条件付きで無効にします-これらの修正はアップストリームされません。ダウンストリームユーザーはXargoを使用してAVRの縮小されたlibcore
をコンパイルできるため、厳密には必要ありません。
+1! コンパイラ本体に組み込まれているAvrrustは非常に便利です。 今ではほとんどバグがありません。
完全にバグがないわけではありません:)
説明を更新して、バックエンドのバグの状態に関する情報を追加します
ほとんどですが😄。 行くだけのカップル
一般的に、メンテナンスの負担がかからない限り、rust-lang / rustの上流にあるプラットフォームを歓迎します。 あなたが考えていることからのいくつかの特定の考え:
#[cfg]
をもっと処理したいと思います。 これらのアイテムは「LLVMのバグ」のために除外されていますか、それともAVRでは基本的にまったくサポートされていないためですか? 前者はどういうわけか「LLVMを修正する」ことによって最もよく行われるでしょうが、後者は物事をよりトリッキーにします。一般に、現在、libcore / libstdの同じ統一されたインターフェイスを備えたすべてのプラットフォームがありますが、さらに多くのプラットフォームを選択し続けるので、それが真実であり続けるかどうかは明らかではありません。
あなたが持っているパッチはかなり良さそうですが、libcoreのさまざまな#[cfg]を通してもっと作業したいと思います。 これらのアイテムは「LLVMのバグ」のために除外されていますか、それともAVRでは基本的にまったくサポートされていないためですか?
LLVMのバグが原因です。
私の頭の中の唯一の質問は、 i128
/ u128
タイプのサポートについてです-AVRの場合、これらは実際には役に立たないと思います。 libcore
のi128
サポートはバグのために現在コメントアウトされていますが、十分にテストされたコードパスではなく、実際にはAVRとしてのみレジスタアロケータを実行するため、他の未発見のバグがある可能性があります32バイト相当の汎用レジスタがあります。
AVRでi128
機能する可能性はまだかなりありますが、バックエンドで発生する特定の問題についてはあまりよくわかりません。
前進するための最善の方法は、libcoreが変更なしで、または少なくとも多くなしでコンパイルされたら、実際のパッチを提案することだと思います。
libcoreが変更なしで、または少なくとも多くなしでコンパイルされたら、実際のパッチを提案するのが最善の方法だと思います。
私には合理的に聞こえます!
私の頭の中の唯一の質問は、i128 / u128タイプのサポートについてです-AVRの場合、これらは実際には役に立たないと思います。
AVRでi128
をサポートしないことに対する私の主な恐れは、AVRまたは他の組み込みプラットフォームとの互換性のために128ビット整数の採用に萎縮効果があることです。 たとえば、128ビット整数を使用するライブラリがある場合、それを使用したいAVRユーザーは、使用量を減らすための問題を提出します。 これにより、128ビット整数を移植性を追求するRustコードで使用するのが「安全」ではなくなる可能性がありますが、これは起こりたくありません。
AVRまたは他の組み込みプラットフォームとの互換性のための128ビット整数の採用に対する萎縮効果
ここではそれほど大したことではないと思います。 小さな組み込みデバイスにはすでに大きな制限があり(stdin / stdoutがない、通常はアロケータがないなど)、任意のライブラリにドロップするのは非常に困難です。 最近、AVR GCCのdouble
が実際にはfloat
エイリアスであることを知りました。 その奇妙さを維持するかどうかはわかりませんが、それは木枠にi128
以上の影響を与えるでしょう。
no-stdの場合と同じように、埋め込みに適したクレートを作成するために使用される特別な機能が常にあると思います。
stdin / stdoutなし、通常はアロケータなしなど。
あなたは#![no_std]
エコシステムについて説明しています。 このエコシステムを対象とした図書館があります。 そして、そのエコシステムの一般的なルールは、 libcore
を与えられたものと見なすことです。これには、 i128
も含まれます。 i128
をサポートしない各ターゲットは、このエコシステム内でより大きな萎縮効果を示します。これは、埋め込まれたターゲットの「市場シェア」が、x86ファミリーがあまり関連性のないプレーヤーであるRustエコシステム全体のサブセット内で大きくなるためです。 。
その奇妙さを維持するかどうかはわかりませんが、i128よりもはるかに多くの箱に影響を与えるでしょう。
面白い! f64
をf32
エイリアスする(または提供しない)と、エコシステムにさらに影響を与えることに同意します。 しかし、一貫性を保つために努力できるのなら、なぜそうすべきではないのでしょうか。 i128
を実装することは間違いなく可能です。
i128を実装することは間違いなく可能です。
もちろん、AVRにi128を実装する実際にi128
を使用するコード
しかし、一貫性を保つために努力できるのなら、なぜそうすべきではないのでしょうか。
何との一貫性が問題です。 GCC( f64
== f32
)または他のすべてのRustターゲット( f64
!= f32
)との整合性?
あなたは#![no_std]エコシステムについて説明しています。
そうです、それが私が「私たちがno-stdの場合と同じように、クレートを埋め込みに適したものにするために使用される特別な機能」と言った理由です。 😇
16ビットのusize
パッチを最初にリリースして以来、私の頭の中にある大きな問題は、基本的に、RustとRustのプログラマーはusize
が「ネイティブ」であると想定する傾向があることです。レジスタのサイズ。 AFAIK、これはRustがターゲットとする他のすべてのプラットフォームに当てはまりますが、AVRには当てはまりません。
何との一貫性が問題です。 GCC(f64 == f32)または他のすべてのRustターゲット(f64!= f32)との整合性?
f64
という名前は、文字通り64ビットであることを示しています。 名前に従わないと、Cの場合と同じように意味がなくなります。
ここでの良い点は、128ビット整数に関する懸念を見ることができます。 それらの使用を奨励するべきではありませんが、私は間違いなくそれらがサポートされるべきだと思います。 i128
タイプのトレイトインプルのようなもののためにクレートが機能フラグを追加しなければならないのを見たくありません。 未使用のi128のものはすべてリンカーによって削除される必要があるため、これは実際には問題にはなりません。
f32 / 64の問題は興味深いものです。 f64を実際に64ビットにすることに関する私の主な懸念は、CFFIが非常に脆弱である可能性があることを意味することです。 開発者がAVR-GCCが32ビットのdoubleを使用していることを知らない場合、FFIを介した呼び出しは初期化されていないメモリまたはセグメンテーション違反を読み取る可能性があります。
ユーザーが代わりにlibc
クレートの型を使用することを期待することで、これを多かれ少なかれ解決できると思います。 AVR固有の機能を追加して、 c_double
をf32
ます。 人々がFFIバインディングでlibc
クレートを使用することを合理的に期待できると思います。
main()署名で使用されます
@matticoたぶん私は奇妙な方法で物事をやってきたのかもしれませんが、私のコードはどれもRustのmain
利用してい
#[no_mangle]
pub extern fn main() {
さらに重要なのは、に戻るものがないため、実際に戻ることができないことです。 すべてのプログラムは永久に実行する必要があります。
@matticoタイプがAVRのGCCと一致するように、libcを変更する必要があります
ああ、絶対に、 main
が私たちに影響を与えるかどうかはまったくわかりません。
@shepmaster埋め込まれていないプラットフォームでも、メインのargc
のサイズは、これまでずっと間違っていて、IRを検査するとき以外は誰も気づいていないことを考えると、問題ではありません。 プロセスに標準のmain()エントリポイントを使用するRTOSがあるかもしれませんか? とにかく、修正するのは簡単です。
修正を送信するのに、これを入力するのと同じ時間がかかったと思いますが、今はそれについて考えています😄
このマージを妨げるのはlibcoreの問題だけですか? だから私たちはどこに努力を集中するべきかを知っています。
私がlibcoreで抱えていた唯一の問題は、何が原因かわからないために発生した奇妙なリンカーエラーと、32ビットビットシフトエラー(本質的に欠落していると思います)です。 しかし、それらがマージをブロックしているかどうかはわかりません。
chocol4te:このマージを妨げるのはlibcoreの問題だけですか? だから私たちはどこに努力を集中するべきかを知っています。
はい-ここで必要な作業はすべてLLVM内で行う必要があり
Restioson:libcoreで発生した唯一の問題は、何が原因かわからないために発生した奇妙なリンカーエラーと、32ビットビットシフトエラー(本質的に欠落していると思います)です。
これは、AVRバックエンドをチョークにするすべてのコードがコメント化されているためです:)
Restioson:しかし、それらがマージをブロックしているかどうかはわかりません。
直接ではありませんが、バックエンドがマージされる前に修正しておくとよいでしょう。 このような非常に厄介なバグがいくつかあり、マージする前に修正することを検討する必要がありますが、必ずしもそれを維持できるとは限りません。
@ dylanmckayLLVM6がマージされましたhttps://github.com/rust-lang/rust/pull/47828-これはこのRFCにとって何を意味しますか?
@kellerkindt 「AVRバックエンドの現在の問題」にリストされているすべての問題はまだ真実です。 avr-rustの現在のHEADがリベースされ、興味深いRust固有のコードがマージされる可能性がありますが、それでも機能するコードは得られません。
私は個人的にまだ賛成です
libcoreが変更なしで、または少なくとも多くなしでコンパイルされたら、実際のパッチを提案するのが最善の方法だと思います。
余分なリベースを避けなければならないのはいいことですが。
Rust on AVRの現状は、半年後に開発が進んでいるのではないかと思います。 私は自分の町で小さなArduinoプロジェクトグループを運営しており、代わりにRustを使用できるようにしたいと思っています。
だから、良いニュースです!
libcoreが変更なしで、または少なくとも多くなしでコンパイルされたら、実際のパッチを提案するのが最善の方法だと思います。
これが事実です!
現在のavr-rustフォークには、 libcore
への変更は含まれていません。
ストックRusからAVRをサポートするために必要な変更は次のとおりです。
LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...}
が宣言され、呼び出されます。avr-unknown-unknown
が追加されました。 これは、明示的に指定されていない限り、最小公分母を構築するavr-gccのデフォルトの動作をモデル化します。 -mmcu=<avr mcu name>
引数を明示的にサポートするavr-gcc
とは異なり、AVRにはAVR固有のコマンドライン引数は追加されていません。 つまり、プロジェクトごとにカスタムターゲット仕様のJSONファイルを作成する必要があります。 ただし、これは多くのRust組み込みプロジェクトに当てはまります。config.toml.example
ファイルに追加されます。 AVRはデフォルトでアップストリームRustに含まれるべきですか、それともオプトインである必要がありますか?"avr-interrupt"
呼び出し規約が追加されました。 これにより、 extern "avr-interrupt" fn my_isr_handler() { .. }
が許可されます。 これはおそらくRFCプロセスを経て安定する必要がありますが、私は間違っている可能性があります。#[cfg(target_cpu = "...")]
が追加されました。 実装はここにあります。 これの実装はターゲットに依存しないため、ARMなどの他のアーキテクチャのCPUに基づく条件付きコンパイルでも機能します。 これにより、 ruduino
クレートに、シリコンでサポートされているすべてのIO、レジスタ、およびモジュールを公開するデバイス固有のモジュールを条件付きで含めることができます。 これは、アップストリームの前にRFCプロセスを通過する必要があります。バックエンドの非実験的ステータスへの昇格に関して、RFCをLLVM-devに送信する時が来たと思います。
ここで、アップストリームRustからavr-rustへの変更の完全なセットを確認でき
現時点で厳選した過去2か月のLLVMパッチはまだいくつかありますが、LLVMのemscriptenバージョンを他のすべてのターゲットに使用されているLLVMのバージョンから分離するための上流のRustの取り組みにより、非常に簡単に導入できます。これらはrust-lang/llvm
リポジトリから変更されます。これは、アップストリームで定期的に更新されるようになったためです。
私たちが持っている4つ未満のチェリーピックLLVMパッチは、現在アップストリームLLVMでレビューされているため、レビュー担当者が十分な時間を見つけると、それらのパッチは自動的にアップストリームRustにフロートします。 アップストリームRustにはターゲット固有のRust固有のパッチもあるため、厳選されたLLVMパッチは、おそらくavr-rustをアップストリームにマージするためのブロッカーではありません。
AVRのRustのステータスに関する最新情報はありますか?
知りたい! 今のところ、STM32の青い錠剤をハッキングすることにしましたが、錆びたavrのサポートの準備ができたら、間違いなくarduinoに戻りたいと思います。
私たち@slowtecは、AVRプロジェクトにもRustを使用したいと
バンプ、サポートが公式になるのを楽しみにしています。 プロジェクトにフォークを使用してみます。
更新:現在、フォークを新しいバージョンのRust(avr-rust / rust#137)にアップグレードしています。 私たちが見つけた2つのバグがあります。
LLVMエラー:レジスタ割り当て中にレジスタが不足しました
これは、llvm / llvm-project @ 45eb4c7e55341c0b83a21dedecc092e273795edaのLLVMトランクで修正されてい
LLVMエラー:選択できません:t2:i16 = addrspacecast [1-> 0] undef:i16
t1:i16 = undef
機能中:_ZN4core3ptr87_ $ LT $ impl $ u20 $ core..fmt..Debug $ u20 $ for $ u20 $ unsafe $ u20 $ fn $ LP $ A $ RP $$ u20 $。$ GT $$ u20 $ Ret $ GT $ 3fmt17h0fdf8ca7140def9b
これは修正が難しいです。 これは、メインメモリとプログラムメモリにアクセスするための2つの別個のポインタアドレス空間があるハーバードアーキテクチャでの関数ポインタのRustの誤った処理が原因です。
説明は@ ecstatic-morseによって行うのが最適です
根本的な問題は、* const Tが常にaddrspace(0)を持っていることです。 明示的なキャスト(ptr as * const T)は、ここでの入力のアドレス空間を保持する必要があると思います。
このバグは、関数と関数ポインターのstd::fmt::Debug
実装によって明らかになります。 Rustは、必要に応じてビットキャスト(iN-> iMビット)またはアドレス空間キャストを暗黙的に挿入するLLVMルーチンを使用して、ターゲットポインタータイプがaddrspace(0)* i16
ポインター逆参照を発行します。 関数ポインターの場合、Rustはaddrspace(1)* i16
ポインターをコード生成する必要があります。これにより、メモリマッピングがないため、LLVMが( addrspacecast
)PROGMEMポインターをRAMポインターにマップする必要がなくなります。また、アドレス空間は重複しません。
このバグが主なブロッカーです。
上流のRustがLLVMマスター(AFAICT、ほとんど8.0リリース)からプルして、たくさんのチェリーピックを削除できるようになることを望んでいます。
私は最近、 https://github.com/dylanmckay/avr-compiler-integration-tests/テストをAVRエミュレーターを使用して成功させました
更新@dylanmckayをありがとう。 私たちは皆、あなたがこれに費やした努力に感謝します。
これで、Rustベースの上のフォークがアップグレードされました。rust -lang/
この問題は失速しましたか?
これに関する最新情報はありますか? PRはまだアドレス空間の問題で行き詰まっていますか?
ねえ@dylanmckay 、これで
みなさん、こんにちは。私からのコメントです。
さくらんぼ狩りの修正
libcore
機能させるために必要な修正のほとんどすべてが、LLVMマスターにアップストリームされており、現在rust-lang / llvmフォークに存在しています。 昨日、AVRフォークを1.39.0(avr-rust / rust#155)に更新するためのPRを開始しましたが、まだ存在していない修正を1つだけ選択する必要がありました-avr-rust / llvm @ 4350776601bc671e6e055bfbe32add34b70d2635。
libcoreは変更せずにコンパイルすることはできません
AVRを使用するためにカスタムlibcoreフォークはもう必要ありません。 現在、avr-rustフォークのlibcore
に対する変更は1つだけです-avr-rust / rust @ 44240ac59c5949b8a9fd191f5cd666d0206fbe85-ポインターキャストを書き直して、正しいIRを生成します。
AVR-Rustバイナリのコンパイルはxargoに依存してい
'call'以外の関数ポインタに対する操作は、プログラムメモリではなくRAMにアクセスします(avr-rust#68)
これは修正されました。
32ビットシフトは、存在しないcompiler-rtルーチンへの呼び出しを生成します(avr-llvm / llvm#163)
これはまだ苦痛な問題です。 最善の修正は、LLVM AVRバックエンドにカスタムの下降コードを記述して、これらのシフトを純粋なアセンブリに下降させ、compiler-rtまたはlibgccへのABIの依存関係を削除することだと思います。 生成されたコードサイズがどれだけ大きくなるかはわかりませんが、それは良い考えではないかもしれません。
このコメントをスレッドに投稿しました
「avr-interrupt」呼び出し規約が追加されました。 これにより、extern "avr-interrupt" fn my_isr_handler(){..}が可能になります。 これはおそらくRFCプロセスを経て安定する必要がありますが、私は間違っている可能性があります。
RFCプロセスを経ずに、不安定な呼び出し規約を追加できますか?
現在、 #![feature(abi_avr_interrupt)]
機能ゲートの下に"avr-interrupt"
と"avr-non-blocking-interrupt"
があります。 これらは、将来の安定化RFCを待つ間、不安定な呼び出し規約としてアップストリームできますか?
LLVMバックエンドをアップストリームするには、そのバックエンドのテストを実行する専用のビルドボットをセットアップし、それを維持する必要があります。 これはRustの場合ですか? プッシュするたびにテストスイートがAVRモードで実行されるようにするにはどうすればよいですか? 他のバックエンド(WASMなど)は何をしましたか?
「avr-rustフォークをアップストリームにマージする」とは、単に2つのフォークを1つにマージすることを意味しますが、それでもソースからのビルドが必要ですか? おそらく、バックエンドを配布することは可能ですが、夜間のみですか? 他のバックエンドは何をしましたか?
それを除けば、avr-rust固有のパッチは非常に薄く、最近では厄介なハッキングはありません。
完全なパッチセットはここで見ることができますhttps://github.com/rust-lang/rust/compare/master...avr-rust:avr-support
私のWIP1.39.0リベースパッチセット(ほとんど同じです)はここで見つけることができますhttps://github.com/rust-lang/rust/compare/master...avr-rust:avr-support-1.39.0-4560ea788c 。 これは、数日以内にavr-rust / masterにマージされるはずです。
これを妨げている具体的なことは何も考えられません。おそらく、パッチを送信して、それがどのように行われるかを確認するときが来たのでしょうか。
https://github.com/rust-lang/rust/issues/44036
この問題については上で述べましたが、AVRバックエンドのアップストリームをブロックするとは思いません。 動作する便利なバージョンのrustcをAVRなしで着陸させることができるはずです。 私たちが再実行できる回避策とハックがあると確信しています。 バックエンドが仮想的にマージされた後、公式のtarget-cpuクエリAPIが公式のRustに到達する前に、AVRクレートでのデバイス検出。
彼は住んでいる! 更新@dylanmckay 、エキサイティングな進歩をありがとう。
素晴らしい仕事@dylanmckay! 情報を提供していただきありがとうございます。
少し話題から外れていますが、avrのrustcはCライブラリでFFIを実行できますか?
すでにavrで利用できるが、C / C ++で記述された成熟したライブラリがたくさんあります。
それらのためにいくつかのrustスタイルのラッパーを作成し、それらをrustavrプロジェクトで再利用できるのは素晴らしいことです。
Rustはすでに一般的にCでFFIを行うことができます。
はい、それは本当に素晴らしいです! 問題は、しかし、それはrust-avrに変換されますか?
AVR用のLLVMのCABIがgccのCABIと一致する限り、動作するはずです。
RFCプロセスを経ずに、不安定な呼び出し規約を追加できますか?
私の投票は「はい」です。AVR呼び出し規約をサポートするための変更は、基本的には名前を付けてLLVM番号にマッピングすることです。 不安定な規則はすでにサポートされているため、基本的なコード変更は必要ありません。
LLVMバックエンドをアップストリームするには、そのバックエンドのテストを実行する専用のビルドボットをセットアップし、それを維持する必要があります。 これはRustの場合ですか? プッシュするたびにテストスイートがAVRモードで実行されるようにするにはどうすればよいですか? 他のバックエンド(WASMなど)は何をしましたか?
Rustのティアシステムは少し大まかに定義されていますが、正しいことはAVR固有のコードをマージます。 その場合、AVRはティア3になります。つまり、AVRは自動的に構築またはテストされるのではなく、コードにぶら下がっているだけです。 少なくとも、これは、これらのファイルがコンパイラーの変更によって最新に保たれることを意味します。
「avr-rustフォークをアップストリームにマージする」とは、単に2つのフォークを1つにマージすることを意味しますが、それでもソースからのビルドが必要ですか?
私の知る限り、 1つのコミットをPRとして提出することになるでしょう。 私たちのカスタムフォークは、より広く使用されるターゲットになるまで、効果的に死ぬ/ AVR固有の詳細を追跡する場所になります。
おそらく、パッチを提出する時が来ました
そう思います。
@edvorgトピックIMOについて
少し話題から外れていますが、avrのrustcはCライブラリでFFIを実行できますか?
すでにavrで利用できるが、C / C ++で記述された成熟したライブラリがたくさんあります。
はい..ほとんど。 AVRバックエンドによって実装されるAVR呼び出し規約は、AVR-GCC(ここに記載さD68524で修正する必要があります。
Rustコールサイトは常にRustまたはavr-clangコンパイル済み関数を正しく呼び出すことができ(avr-clang CはRustフロントエンドと同じextern "C"
呼び出し規約の実装を使用するため)、AVR-GCCとの相互運用が機能するはずです。特に単純な関数シグネチャの場合ですが、時々チョークする可能性があります(詳細については、D68524の説明を参照してください)。
これに関する更新はありますか?
ちょっと興味があるんだけど。
LLVMAVRバックエンドを公式バックエンドにするためのリクエストを送信しました-https ://reviews.llvm.org/D75099
@dylanmckay受け入れられた場合、この問題を解決するための残りの部分は何ですか?
@dylanmckay受け入れられた場合、この問題を解決するための残りの部分は何ですか?
技術的には、Rustは公式バックエンドと実験的バックエンドの両方で動作します。 バックエンドの大部分をアップストリームするために#69478を調達しました。
AVRをTier3ターゲットとしてマージすることが、AVRが公式のLLVMバックエンドになることを前提としているかどうかはわかりません。考えを歓迎します。
考えてみると、LLVMの公式と実験の違いは、Rustの層システムにマッピングできます。Rustには3つの層があり、LLVMには2つの層があります。 LLVMの公式バックエンドは、Tier 1とTier 2の組み合わせに対応します。基本的に、テストスイートと公式リリースに含まれています。 LLVMの実験的なバックエンドは、私が知る限り、意味的にはRust Tier3バックエンドと同じです。 ソースツリーに含まれている、デフォルトではリリースに含まれていない、デフォルトのCIテストには含まれていないなど。
次に、この問題を解決するために残っているのは、#69478のコードレビューで出てくるものだけだと思います。
tl; dr AVRバックエンドは、マージされた場合、rust-lang / rust#69478のTier 3アップストリームターゲットになり、フォークを強制終了します。
avr-rust / rustフォークと#69478の唯一の違いは、AVRフォークには存在するがアップストリームには存在しないtarget_cpu
cfgフラグです。 私はそれを最初のPRから除外しました。
残りの部分は何ですか
さまざまな種類のコードの誤コンパイルがまだたくさんあると確信しているので、物事を試し、バグを最小限に抑えて修正するには、さらに多くの人が必要です。
ただし、通常は古くなったフォークをコンパイルする代わりに、毎晩通常のRustを取得できるため、アップスチームを実行すると、人々に試してもらうための基準が低くなります。
Tier 3ターゲットとしてアップストリームされると、AVR開発は貨物の-Z build-std
機能で機能しますか、それともxargoが必要ですか? Rustに同梱されているLLDはAVRをサポートしていますか、それともgnuリンカーが必要ですか?
AVR開発は貨物の
-Z build-std
機能で機能しますか、それともxargoが必要ですか? Rustに同梱されているLLDはAVRをサポートしていますか、それともgnuリンカーが必要ですか?
それらが機能しないとは言えませんが、私が行ったことはすべてXargoおよびGNUリンカーを使用しています。
GNUリンカはWindowsでセットアップするのが難しく、xargoをインストールするにはもう1つのツールが必要です。それが、私が求めている理由です。
Rustに同梱されているLLDはAVRをサポートしていますか、それともgnuリンカーが必要ですか?
LLDはAVRをリンクするための非常に基本的なサポートしか持っておらず、実際のプログラムをまだリンクすることはできません。 したがって、 avr-ld
が必要になります。
それが私が求めている理由です。
間違いなく、それが正しい最終目標だと思います。それは世界の現状ではないかもしれません。 正直なところ、オーバーヘッドをどんどん低くしていきたいと思います。 マージすることは、そのための最初のステップにすぎません。
AVRバックエンドが公式のLLVMターゲットとして有効になりました:tada:LLVMマスターにはデフォルトでAVRサポートが含まれています。 デフォルトでAVRを含む最初のLLVMリリースは、約6か月後にLLVM11になります。
良い! あなたがこれに注いでいるすべての努力に感謝します。
とてもかっこいい!
この信じられないほどの成果を@dylanmckayおめでとうございます。 コミュニティはこれに取り組んでくれてありがとう。
私はしばらくの間この問題をフォローしてきましたが、これはほとんどトピックから外れていることはわかっていますが、これがソースユーザーからではなく平均的なユーザーにとって何を意味するのか興味があります... Arduino Unoは、これを使用してネイティブRustで稼働していますか? Rustには十分な保護機能があるので、私はこれに最も興味があります。
@ Jimmio92私が言えることから、そうです。 「はい、それは複雑です」のように。 または、Rustコンパイラのこのカスタムフォークをソースからビルドする必要があるため、特に複雑ではないにしても、少なくとも長くて退屈です。これには、ソースからLLVMをビルドする必要もあります。 すべてがうまくいけば、それは通常数時間かかり
しかし、LLVMでの私の個人的な経験では、多くの場合、システム上の何かが気に入らないだけです(少なくとも、macOSでは、Linuxの方が簡単で、Windowsでこれを行うことさえ夢にも思わないでしょう)。そのため、成功するか諦めるまで、必然的にインストールパスとカスタムライブラリをマッサージすることになります。
上記の(優れた)ニュースが意味するのはこれだけです。LLVMの開発者は現在AVRを公式にターゲット/サポートしています(?)。LLVMの次のリリースにはAVRサポートが含まれます。 Rustが現在AVRもサポートしているか、短期的にサポートすることは言うまでもありません。 問題と上記のコメントを見ると、AVRサポートがストックのRustツールチェーンで「正しく機能する」までには多くの作業が必要であることがわかります。
LLVMマスターからRustLLVMフォークへのチェリーピッキングAVR修正を見ることができるプロセス/例はありますか?
また、RustはまだLLVMマスターを追跡しますか? その外観から、現在のリリースに加えて、厳選されたいくつかの修正を追跡します。 LLVMバージョンをマスターに更新するPRは引き続き受け入れられますか?
@dylanmckay
また、RustはまだLLVMマスターを追跡しますか?
お気づきのように、リリースを追跡しています。
LLVMバージョンをマスターに更新するPRは引き続き受け入れられますか?
私はそうは思いませんが、cc @nikic
@dylanmckay 10.0リリースと比較してRustのLLVMフォークにます: //github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05
LLVMマスターからRustLLVMフォークへのチェリーピッキングAVR修正を見ることができるプロセス/例はありますか?
ここで利用可能な手順があります: https ://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates
また、RustはまだLLVMマスターを追跡しますか? その外観から、現在のリリースに加えて、厳選されたいくつかの修正を追跡します。 LLVMバージョンをマスターに更新するPRは引き続き受け入れられますか?
Rustは現在LLVMリリースを追跡しています。これにより、対応するclangバージョンを使用して言語間のLTOを簡単に実行できるようになります。 したがって、ここでのデフォルトの答えはおそらく「いいえ」です。
とはいえ、LLVM10のコンパイル時のリグレッションを軽減するためにLLVMマスターに更新することについてはいくつかの議論がありました。 私は現在、評価の目的でそれに取り組んでいます。 しかし、これが起こらないと想定して、LLVM 10フォークに対してチェリーピックを提出する方が安全だと思います(たくさんありますか?)
フォークが統合されました! 私は今日の午後に適切な更新を書きます
私は今日の午後に適切な更新を書きます
私は上記の更新に興味があります。 @dylanmckayをどこに投稿する
私は文字通り何年もの間、Rustエコシステムへのこの追加を熱心に待っていました! しかし、マスターでこれを使用しようとする私の素朴な試みには欠陥があるようです。
私は標準の./x.py build
でマスターラストを構築し、ツールチェーンmaster
としてリンクし、次にavr-rust / blinkの例を構築しようとしました( src/main.rs
を更新してllvm_asm!
を使用した後)
RUST_TARGET_PATH=`pwd`
XARGO_RUST_SRC=/home/nixpulvis/Projects/rust
rustup run master xargo build --target avr-atmega328p --release
これは次の場合に失敗します。
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
不足している構成がまだ必要であると想定しています。
@nixpulvisはhttps://github.com/rust-lang/rust/issues/44052#issuecomment-591396417を参照して
libcoreは誤ってコンパイルされたものの一部であるため、今はほとんど何も機能しないと思います。
AVRrustcフォークは上流に統合されました。
上流のフォークはまだ一般的に使用できません。 最初に行う必要があることがいくつかあります。
@nikicの質問に答えるために、チェリーピックする必要がある最大20のLLVMコミットがあります。
私はスクリプトを使用して、LLVMアップストリームからローカルフォークに_all_AVRコミットを自動的に選択しました。
これは大きなハンマーであり、不要な修正があります。バックエンドが使用可能になる前に、上流のRustにプルする必要がある上流のLLVM修正があります。 それらはフィルターで除去され、上流のRustにチェリーピックされる必要があります。
上流の取り組みが数ヶ月続いているので、下流のavr-rustフォーク
まだRustの特に古いバージョンにあります。 それ以来、上流のRustに少なくとも1つの変更があり、LLVMアサーションエラーに遭遇することなくAVRをサポートするために一般化が必要です。 プルリクエスト#73270を開いて修正しました。
AVRの変更が必要なアップストリームRustに他の変更があったかどうかはわかりませんが、おそらくそうではありません。
まばたきプログラムが機能するようになったら、別の更新を投稿します。その時点で、アップストリームAVRサポートが使用/実験の準備ができているはずだからです。
@wezmあなたは良い点を挙げます-更新のための「祝福された」コミュニケーションチャネルは必ずしもありません。 このチケットはうまく機能しましたが、必然的に間もなく終了します。
AVR-Rust Gitterチャンネルは、最も自然な既存の選択肢です。 私はメーリングリストのアイデアが好きです(しかし、可能であればメールサーバーをホストするというアイデアは好きではありません)。 Gitterチャンネルにはディスカッションが含まれているので、おそらくメーリングリストのようなものが役立つでしょう。
おそらく、ブログを設定することは、アナウンス/更新を一元化するのに良いでしょう。 さりげなくアップデートしたい人が見逃さないように「公式メディア」を作りたいです。 ブログは新しい投稿を常にチェックする必要があると思いますが、メーリングリストは本質的に通知します
興味のある方。 提案を歓迎します。
(rustc version, Xargo version)
テーブルが必要なので今のところ、より良いメディアが見つかるまで、このGitHubの問題に更新を再投稿するようにします。 Gitterにも投稿します。
おそらく、ブログを設定することは、アナウンス/更新を一元化するのに良いでしょう。 さりげなくアップデートしたい人が見逃さないように「公式メディア」を作りたいです。 ブログは新しい投稿を常にチェックする必要があると思いますが、メーリングリストは本質的に通知します
興味のある方。 提案を歓迎します。
私の個人的な好みは、ブログ(RSSフィード付き)を強く支持しています。 ブログは通常、検索エンジンの結果に表示されやすく、メーリングリストのスレッドよりもリンクしやすいと思います。 RSSフィードは、チェック/通知の側面を解決します。
最適な場所かどうかは100%わかりませんが、EmbeddedWGブログがあります。 コミュニケーションのための労力の少ないチャネルかもしれません。
おそらくTwitterアカウントも? 新しいブログ投稿を共有するために使用できます(最新の状態に保つため)。
埋め込まれたワーキンググループがここで喜んで助けてくれると思います。 Twitterアカウント@rustembeddedを持っており、ニュースレターにもAVR関連のニュースを含めることができます。
また、しばらく前にO-AVR
ラベルを作成したので、AVR固有の問題にもRust Issue Trackerを自由に使用してください(ただし、リポジトリを監視している人が1.5k人いることに注意してください)。 それに加えて、ほとんどのRustチームが存在する場所であるため、rust-langZulipで調整することをお勧めします。 また、特定のRustターゲット(WindowsやArmなど)に焦点を当てた「ターゲットグループ」を立ち上げる過程にあります。AVRもそれに適している可能性があります。 これについては、Zulipにお気軽にお問い合わせください。
アップデート。
libcore
をストックのrust-lang / masterブランチでAVR用にコンパイルする前に、2つのことが残っています。
addrspace(1)
としてタグ付けする方法に関連する、AVRの一連の「アドレス空間キャスト無効」バグを修正するプルリクエストが1つあります。 addrspace(0)
。 rust-lang / rust#73270-現在コードレビュー中です。〜2。 blink
例が機能するのを妨げるもう1つのバグがあります-avr-rust / rust#92。 それを修正するまだアップストリームされていないパッチがあります-https://reviews.llvm.org/D68524。 これはアップストリームになり、ユニットと統合テストに合格すると
これらの2つのことが完了すると、アップストリームされたRust AVRターゲットはAVRコードを現在のavr-rust / rustフォークと同じレベルにコンパイルできるようになり、 blink
例を更新するプロセスを開始できます。 、 arduino
クレート、ドキュメント、ガイド、アップストリームブランチ用。 これで、アップストリームブランチを実験的に使用できるようになります。
もう1つのTODO:
llvm_asm!
を介して古いマクロを使用できます。これは、夜間にまだ存在しているためです。これがすべてのブランチです: https :
これはアップストリームrust-lang/master
から構築されますが、まだアップストリームされていないLLVMパッチD68524 、まだマージされていないRust PR rust-lang / rust#73270、およびアップストリームLLVMからの46のAVR関連コミットが自動的にチェリーピックされます。スクリプト(LLVMブランチ:https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate)。 46のすべてが必要なわけではないことに注意してください。最終的なリストは、より小さくなります。
更新:すべてのアップストリームLLVM修正を含むプルリクエストを開きました。
これは、LED点滅プログラムをコンパイルして正常に実行する前の残りの作業の完全なリストです。
--eh-frame-hdr
引数をリンカーに無条件に渡し始めました。 AVR-GCCリンカーはこのフラグをサポートしていないため、Windowsの既存の除外と同様に、このフラグを渡さないようにするための特別なケースがAVRに追加されます。 Solaris、およびUEFI。おそらく、ツールを直接Cargoに追加する方が良いでしょう(これには追跡の問題があります)。
これが正しい問題だと思います:rust-lang / cargo#4959。
cargo build -Z build-std=core
は私のAVRサンプルケースでうまく機能しました。
とにかく私を近づけているように見える@shepmaster 、ありがとう! 私は今ビットキャストのものに固執しているように見えるので、それがマージされるのを待ちます(PRとIDKを構築するために必要なファイルが欠落しているように見えるため)。
-Z build-std=core
を使用する過程で、ターゲットトリプルを指定する必要があったため、 rustc +master --print target-list | grep avr
、 avr-unknown-unknown
を見つけました。 しかし、アーカイブされた問題avr-llvm / llvm#35は、トリプルが実際にはavr-atmel-none
必要があるように聞こえるようです(とにかく私にはもっと理にかなっています)。 ここで何かを更新する必要がありますか、それとも何かが足りませんか?
avr-unknown-unknown
は正しいです。
未解決の質問
* 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?
これはユーザー側ではそれほど重要ではないと思います。 これは、ddgおよび/または今週のさびで見つけるのに十分簡単でした。
開発者にとってそれを容易にするものは何でも。
未解決の質問
* 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?
これはユーザー側ではそれほど重要ではないと思います。 これは、ddgおよび/または今週のさびで見つけるのに十分簡単でした。
開発者にとってそれを容易にするものは何でも。
RustをAVRでコンパイルするための手順は、 https: //docs.rust-embedded.org/にあるはずです
了解しました。更新時刻です。
AVRに必要なすべてのパッチは、今日のrustc 1.47.0-nightly (0820e54a8 2020-07-23)
の時点で、現在のRustナイトリーコンパイラーに存在します。 Rustナイトリーコンパイラは、変更なしで、LED点滅の例を正常にコンパイルし、AVRELFファイルを生成できるようになりました。
-Z build-std
フラグが、AVRでのXargoの必要性に取って代わります。 カーゴフォークは不要になりました。上流のカーゴで十分です。Rustナイトリーコンパイラは、AVRをサポートするRustの推奨チャネルと見なすことができます。
私は今この問題を閉じています-私たちはそれをしました!
バグを報告する手順は、 AVRガイドブックに記載されています。
AVRガイドブックとhttps://github.com/avr-rust/blinkのblinkの例は、ターゲットの使用を開始するための最良のリソースです。
この上流の取り組みを通じてプロジェクトについて話し合い、支援してくれたすべての人に深く深く感謝します。これは非常にありがたいことです。
フィン
すごいすごいすごい。
これに貢献してくれたすべての人に感謝します–私は永遠からこの日を楽しみにしていました!
錆をavrに移植する前のディラン・マッケイ
以降
頑張ってくれてありがとう! :-)ゆっくり休んでください!
最も参考になるコメント
了解しました。更新時刻です。
AVRに必要なすべてのパッチは、今日の
rustc 1.47.0-nightly (0820e54a8 2020-07-23)
の時点で、現在のRustナイトリーコンパイラーに存在します。 Rustナイトリーコンパイラは、変更なしで、LED点滅の例を正常にコンパイルし、AVRELFファイルを生成できるようになりました。-Z build-std
フラグが、AVRでのXargoの必要性に取って代わります。 カーゴフォークは不要になりました。上流のカーゴで十分です。Rustナイトリーコンパイラは、AVRをサポートするRustの推奨チャネルと見なすことができます。
私は今この問題を閉じています-私たちはそれをしました!
バグを報告する手順は、 AVRガイドブックに記載されています。
AVRガイドブックとhttps://github.com/avr-rust/blinkのblinkの例は、ターゲットの使用を開始するための最良のリソースです。
この上流の取り組みを通じてプロジェクトについて話し合い、支援してくれたすべての人に深く深く感謝します。これは非常にありがたいことです。
フィン