シミュレータ用のコードをいくつか作成し、現在 TI の無料ツールチェーンを使用して 64kb の NVRAM を持つターゲットにクロスコンパイルしようとしています。コンパイラは、私のコードは ROM より約 34kb 大きいと主張しています。
(...) msp430-elf/bin/ld: region `ROM' overflowed by 33716 bytes
別の行には、割り当てられたスペースにフィールドを収めることができない、と書かれています.text。追加した合計サイズが 34kb であること、ましてやバイナリがこの量だけオーバーフローするなんて、信じられません。
- 私のコードがプロジェクトに追加した .o ファイルは、プロジェクト全体のごく一部 (1.9 MB のうち 200 KB) であり、プロジェクトに最初から含まれていたコンポーネントの多くを削除しました。
- すでにコンパイラに
-Os -sフラグを渡しています。 - 新しいコードには約 100 文字分の文字列リテラルが含まれています。
- 私のコードは多くの
math.h関数を使用しており（実際、浮動小数点演算を行うのはここだけです）、を呼び出しstrtod、を呼び出します。sprintf
バイナリがこれほど大きくなる原因を解明するツールや方法はありますか?
ベストアンサー1
GNU binutils には、各シンボルまたは各オブジェクト ファイルのサイズを決定するのに役立つツールがあります。
sizeたとえば、次のものをご覧ください:https://manpages.debian.org/jessie/binutils/size.1.en.html
nmオブジェクト コード内の各シンボルのサイズを表示できるので、試してみる価値もあります。https://manpages.debian.org/jessie/binutils/nm.1.en.html
と の出力を注意深く検査するとsize、nm何が多くのスペースを占め、何がそうでないかを直感的に把握できるようになります。
printf、sprintfおよびより複雑なライブラリ関数の多くは、多くの場合、かなりの数 KB の追加 ROM を占有する可能性があることに注意してください。
ソフト浮動小数点を使用した浮動小数点サポートは、ハード浮動小数点を使用する場合、つまり浮動小数点を処理するためにソフトウェア エミュレーションとハードウェア命令を使用する場合と比較して、コードが肥大化します。
時々、コンパイラは驚くほどの量の肥大化を追加します :)