3

objcopy を使用して、リソース ファイル (zip ファイル) をフラッシュ メモリ (ARM に埋め込まれたもの) に埋め込むために必要なスクリプトを削除しています。

私は次のようにobjcopyを使用しています：

arm-none-eabi-objcopy.exe -I binary -O elf32-littlearm -B arm --rename-section .data=.rodata input.zip input.zip.o
arm-none-eabi-nm.exe -S -t d input.zip.o
00006301 R _binary_input_zip_end
00006301 A _binary_input_zip_size
00000000 R _binary_input_zip_start

私が知る必要があるのは、_end および _size シンボルの幅です。_start は、バイト配列のようにアクセスできるアドレスであると推測できます: extern uint8_t _binary_input_zip_start[];. そして、_end と _size は「ネイティブ」の int サイズであると想定しています。これらを uint32_t として解釈できると安全に想定できると思います。

しかし、私は確信が持てません。objcopy のドキュメントに関連する「サイズ」が見つかりません: https://sourceware.org/binutils/docs/binutils/objcopy.html

4

1 に答える 1

0

これが機能するかどうかは 100% わかりませんが、オプション --sort-size を arm-none-eabi-nm に追加してみてください。これは、シンボルを上の次のシンボルと比較して、サイズでソートすることになっています。-S オプションと組み合わせると、サイズが出力されます。うまくいけば、これは幅を推測するのに役立ちます。

どのARMマイクロを使用していますか? 32 ビットが適切な推測ですが、例外もあります。たまたま Texas Instruments の部品を使用している場合は、さらに多くのことをお手伝いできます。これをテストできる便利な ARM プロジェクトはありませんが、試してみる価値はあります。それがうまくいかない場合は、掘り続けます。

出典: 私の知識、およびhttp://manned.org/arm-none-eabi-nmによる再確認

于 2014-12-01T08:09:19.113 に答える