5

ツールチェーン (Yagarto および codesourcery) のサイズ ユーティリティを使用したときに得られる結果に少し混乱しています。データ セクションで 0 バイトを使用していると報告されています。下記参照

$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf
   text    data     bss     dec     hex filename
  79364       0   34288  113652   1bbf4 rest-server-example.crazy-horse.elf

コードでスタティック RAM 変数を使用し、0 以外の値に初期化していることはわかっています。

興味深いことに、リンクされているオブジェクト ファイルの一部にサイズ ツールを直接渡すと、.data セクションが報告されていることがわかります。

例：

   text    data     bss     dec     hex filename
   1648       0      20    1668     684 obj_crazy-horse/uip-nd6.o
    200      12    2652    2864     b30 obj_crazy-horse/uip-packetqueue.o
     12       0       0      12       c obj_crazy-horse/uip-split.o
   1816      24      48    1888     760 obj_crazy-horse/usb-core.o
    284       0       0     284     11c obj_crazy-horse/usb-interrupt.o
   2064      20     188    2272     8e0 obj_crazy-horse/xmac.o

.data セクションを作成するオブジェクト ファイルがゼロ以外の値を報告しているのに、elf ファイルが .data セクションに対して 0 を報告するのはなぜですか?

参考までに、私は AT91SAM7x256 Micro の組み込みソフトウェアに取り組んでいます

編集：

CFLAGS と LDFLAGS を追加する

CFLAGS  += -O -DRUN_AS_SYSTEM -DROM_RUN  -ffunction-sections

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map

編集＃2：オブジェクトダンプから、.dataセクションにデータが割り当てられていることがはっきりとわかりますが、サイズユーティリティは何らかの理由でそれを取得していません objdump link

私が探しているのは、変数の1つが最適化されたかどうかを把握しようとしていないRAMの正確な使用量を取得することだけです。

編集 3: size ユーティリティが .data セクションに何かを見ていることを示す詳細情報

$ arm-none-eabi-size.exe -A -t -x  rest-server-example.crazy-horse.elf
rest-server-example.crazy-horse.elf  :
section              size       addr
.vectrom             0x34   0x100000
.text             0x10fc8   0x100038
.rodata            0x149c   0x111000
.ARM.extab           0x30   0x11249c
.ARM.exidx           0xe0   0x1124cc
.data              0x1028   0x200000
.bss               0x7bec   0x201028
.stack              0xa08   0x20f5f8
.ARM.attributes      0x32        0x0
.comment             0x11        0x0
.debug_aranges      0xc68        0x0
.debug_info       0x2b87e        0x0
.debug_abbrev      0x960b        0x0
.debug_line        0x9bcb        0x0
.debug_frame       0x4918        0x0
.debug_str         0x831d        0x0
.debug_loc        0x13fad        0x0
.debug_ranges       0x620        0x0
Total             0x7c4c5
4

2 に答える 2

2

.data セクションには CODE 属性が設定されており、これにより「arm-none-eabi-size」が混乱します。.data セクションのサイズが、データ サイズではなく合計テキスト サイズに誤って追加されます。

私の推測では、フラッシュに保存されているが、RAM から実行する必要がある高速割り込みハンドラーやフラッシュの再プログラミングなど、実行時に RAM にコピーされるコードがあると思います。これにより、データ セグメントの CODE 属性が設定され、"size" はすべての .data がテキストであると認識します。

于 2015-09-28T14:50:25.120 に答える
2

私の解釈では、リンカ スクリプトは、データ セクションの初期値と、初期化されていないデータ セクションにデータをコピーするスタートアップ コードの一部を含む単一のロード可能なセクションを作成します。

これは、読み取り専用メモリから実行できる単一のイメージ ファイルが必要な場合に必要です。前に ELF ローダーがないため、そのコピーが実行されます。

通常、これは入力セクションを 2 回マッピングするのではなく、セクションからセグメントへのマッピング (つまり、>セクション配置コマンドを使用してリンカー スクリプトで出力セクションを配置する) でのみ行われますが、それも可能です。

使用量の数値は非常に正確です。テキスト サイズは必要なフラッシュ スペースの量であり、BSS サイズは必要な RAM の量です。初期化されたデータは 2 回カウントされます。1 回はフラッシュ内の初期データ用、もう 1 回は RAM 内の変更可能なデータ用です。

于 2012-03-16T14:42:14.523 に答える