現在、最小限の動くプログラムがあります。しかし、エンドユーザーが安全なプログラムをビルドできるようにパッケージを作る必要があります。
このセクションでは、標準のRustプログラムが使うようなmainインタフェースを実装します。
まず最初に、バイナリクレートをライブラリクレートに変換します。
$ mv src/main.rs src/lib.rsそして、クレートを「runtime」を意味するrtという名前に変えます。
$ sed -i s/app/rt/ Cargo.toml
$ head -n4 Cargo.toml{{#include ../ci/main/rt/Cargo.toml:1:4}}最初の変更は、リセットハンドから外部のmain関数を呼び出すようにすることです。
$ head -n13 src/lib.rs{{#include ../ci/main/rt/src/lib.rs:1:13}}#![no_main]アトリビュートも取り除いています。このアトリビュートはライブラリクレートには効果がありません。
ここで、直交する疑問が湧きます。
rtライブラリは標準のパニック動作を提供すべきでしょうか？それとも、#[panic_handler]関数を提供せずに、ユーザーがパニック動作を選べるように残しておくべきでしょうか？ 本ドキュメントでは、この疑問を深堀りせず、単純化のためにrtクレートにダミーの#[panic_handler]関数を残しておきます。 しかしながら、他の選択肢があることを読者に伝えておきます。
2つ目の変更は、これまでに書いたリンカスクリプトを、アプリケーションクレートに提供することです。
リンカがライブラリサーチパス（-L）とリンカを呼び出したディレクトリから、リンカスクリプトを探すことはご存知でしょう。
アプリケーションクレートがlink.xのコピーを持たなくて済むように、ビルドスクリプトを使ってrtクレートが、
ライブラリサーチパスにリンカスクリプトを置くようにします。
$ # `rt`のルートディレクトリに、以下の内容でbuild.rsを作ります
$ cat build.rs{{#include ../ci/main/rt/build.rs}}これで、ユーザーはmainシンボルを公開するアプリケーションを書くことができ、rtクレートとリンクすることができます。
rtは、アプリケーションプログラムに正しいメモリレイアウトを提供します。
$ cd ..
$ cargo new --edition 2018 --bin app
$ cd app
$ # Cargo.tomlを`rt`クレートとの依存関係を持つように修正します
$ tail -n2 Cargo.toml{{#include ../ci/main/app/Cargo.toml:7:8}}$ # デフォルトターゲットとリンカ呼び出しを微調整した設定ファイルをコピーします
$ cp -r ../rt/.cargo .
$ # `main.rs`の内容を下記の通り変更します
$ cat src/main.rs{{#include ../ci/main/app/src/main.rs}}逆アセンブリの結果は似ていますが、ここではユーザーのmain関数を含んでいます。
$ cargo objdump --bin app -- -d -no-show-raw-insn{{#include ../ci/main/app/app.objdump}}
mainインタフェースは機能しますが、簡単に誤った使い方ができてしまいます。
例えば、ユーザーは発散しない関数としてmain関数を書くかもしれません。その結果、コンパイルエラーは発生しませんが、
未定義動作になるでしょう（コンパイラはプログラムに誤った最適化を行います）。
シンボルインタフェースではなくマクロをユーザーに公開することで、型安全性を追加することができます。
rtクレートに、次のマクロを書くことができます。
$ tail -n12 ../rt/src/lib.rs{{#include ../ci/main/rt/src/lib.rs:25:37}}そして、アプリケーション作成者は、このマクロを次のように呼び出します。
$ cat src/main.rs{{#include ../ci/main/app2/src/main.rs}}今度は、アプリケーション作成者は、mainのシグネチャをfn()のような発散しない関数に変更すると、
エラーに遭遇するでしょう。
rtは良さそうに見えますが、まだ機能が完全ではありません！rtクレートに対して書かれたアプリケーションは、
static変数や文字列リテラルを使うことができません。rtのリンカスクリプトが、
標準の.bss、.data、.rodataセクションを定義していないからです。これを直していきましょう！
最初のステップはリンカスクリプトに下記のセクションを定義することです。
$ # ファイルの一部のみを見せます
$ sed -n 25,46p ../rt/link.x{{#include ../ci/main/rt/link.x:25:46}}
これらは入力セクションを単に再度エスクポートし、各メモリ領域のどこに出力セクションが置かれるかを指定しているだけです。
これらの変更で、下記のプログラムがコンパイル可能になります。
{{#include ../ci/main/app3/src/main.rs}}しかし、実際のハードウェア上でプログラムを実行し、デバッグすると、mainに到達した時点で、
static変数のBSSとDATAが、0と1になっていないことに気づくでしょう。
代わりに、これらの変数はゴミデータを持っています。この問題は、デバイスの電源投入時、RAMがランダムなデータを持つためです。
プログラムをQEMUで実行すると、この現象は観測できません。
実は、プログラムがstatic変数に書き込みを行う前に、その変数を読むことは、未定義動作です。
mainを呼ぶ前に、全てのstatic変数を初期化するように修正しましょう。
RAM初期化のために、リンカスクリプトをさらに微修正しなければなりません。
$ # ファイルの一部のみを見せます
$ sed -n 25,52p ../rt/link.x{{#include ../ci/main/rt2/link.x:25:52}}
変更内容を詳細に見ていきましょう。
{{#include ../ci/main/rt2/link.x:38}}
{{#include ../ci/main/rt2/link.x:40}}
{{#include ../ci/main/rt2/link.x:45}}
{{#include ../ci/main/rt2/link.x:47}}
シンボルを.bssセクションと.dataセクションの開始アドレスと終了アドレスに関連付けます。
これらは後ほど、Rustコードで使用します。
{{#include ../ci/main/rt2/link.x:43}}
.rodataセクションの終わりに、.dataセクションのロードメモリアドレス（LMA; Load Memory Address）を設定します。
.dataはゼロでない初期値をもったstatic変数が含まれています。.dataセクションの仮想メモリアドレス（VMA; Virtual Memory Address）は、
RAMのどこかにあります。これは、static変数が配置されている場所です。
しかし、これらのstatic変数の初期値は、不揮発性メモリ（Flash）に割り当てられなければなりません。
LMAは、これらの初期値が格納されるFlashの場所を示しています。
{{#include ../ci/main/rt2/link.x:50}}
最後に、.dataセクションのLMAをシンボルに関連付けます。
Rust側では、.bssセクションをゼロクリアし、.dataセクションを初期化します。Rustコードからリンカスクリプトで作成したシンボルを参照できます。
これらのシンボルのアドレス1は、.bssセクションと.dataセクションの境界になります。
リセットハンドラを、次のように更新します。
$ head -n32 ../rt/src/lib.rs{{#include ../ci/main/rt2/src/lib.rs:1:31}}これで、未定義動作なしに、エンドユーザーは直接的にも間接的にもstatic変数を使うことができます。
上記のコードでは、メモリ初期化をバイト単位の方法で初期化しています。
.bssセクションと.dataセクションを例えば4バイトでアライメントすることが可能です。 このことは、アライメントチェックなしにワード単位の初期化を行うために、Rustコードで使うことができます。 どのようにやるのか興味がある場合、cortex-m-rtクレートをチェックして下さい。