メモリにロードできるファイルを作成し (たとえばmmap
)、そのメモリの先頭にジャンプしてコードを実行したいと考えています。
理想的には、コードを再配置可能にする (これは非効率的かもしれません) か、コードがロードされると予想される明示的なアドレスを指定する (これは面倒です) というオプションが欲しいのですが、どちらもおそらくそれ自体でうまく動作するでしょう。 .
メモリにロードできるファイルを作成し (たとえばmmap
)、そのメモリの先頭にジャンプしてコードを実行したいと考えています。
理想的には、コードを再配置可能にする (これは非効率的かもしれません) か、コードがロードされると予想される明示的なアドレスを指定する (これは面倒です) というオプションが欲しいのですが、どちらもおそらくそれ自体でうまく動作するでしょう。 .
これを行うことができますが、オブジェクト ファイル形式を確認する必要があります。特に、objcopy
コマンドは実行可能ファイルを「フラット」バイナリ ファイルに変換できます (ターゲット プラットフォームによって異なります)。おそらく次のようなものです:
gcc -o test test.c
objcopy -O binary test test.bin
詳細についてman objcopy
は、お使いのプラットフォームで を参照してください。
objcopy
通常、GCC と一緒に使用できるutility について知りたいとします。これは、ツールのbinutilsパッケージのコンポーネントであり、最も目に見えるメンバーはリンカーですld
。
プロセスは、通常どおりソース ファイルをコンパイルし、それらをリンクすることです。これにより、完成した elf (または別の再配置可能なプラットフォーム依存のバイナリ) 形式の実行可能ファイルが得られます。次に、objcopy を使用して、実行可能ファイルをフラット バイナリ イメージに変換します。
これは、ターゲット プラットフォームに適した C ランタイム ライブラリを使用していることを確認し、リンカー スクリプト ファイルをカスタマイズし、独自の C ランタイムを提供する必要がある場合に、ROM から実行するコードを準備する場合に最も役立ちます。起動コード。
.so ファイルのようなものを取得して既存のプロセスにロードすることが目標の場合、共有ライブラリ ローダーの作業の一部は実際にリンクを完了することであり、.so 内のシンボルがメインの実行可能ファイル (または他の .so ファイル) 内のアドレスを参照するファイルは、読み込み時に解決されます。objcopy を使用してもそれができないため、この方法でロードされた関数が、既存の C ランタイム ライブラリと、開いているファイルなど、それが保持するオブジェクトを適切に使用するのが難しい場合があります。
目標に関係なく、バイナリを既知のアドレスに配置するには、リンカーの制御を取得する必要があります。そのためには、リンカー スクリプトを作成する必要があります。スクリプト言語のドキュメントはbinutils manualにあります。主に ".text*" セクションに関心があり、初期化されたグローバル変数を使用する予定がある場合は、おそらく ".rodata*" セクションに関心があります。その初期化を実際に手配することは、読者の課題として残されています。
全体として、これは非常に大きな氷山の一角にすぎません。これらが実際にどのように使用されているかを確認するために、クロスコンパイラのビルドに時間を費やすことをお勧めします。AVR および MSP430 コミュニティは GCC を使用し、積極的に参加し、安価な (そして多くの場合オープン ソースの) ハードウェアを開始します。