これがドメイン固有のものではないことを願っています。libc.a が、チップにある 8K の RAM のうち 1K を使用している理由を知りたいです。
array_initでグローバルオブジェクトのコンストラクターを呼び出す以外に、libcを使用している方法を知りません。私の知る限り、デフォルトのコピー構築にも関与していると思います。私はプール割り当てを使用するため、ヒープ関連のものは使用しません (placement new を使用しますが、私が知る限り、libc が ram を使用することはありません)。ライブラリを完全に除外し、placement new をハックとして使用して main 内のすべてのグローバル オブジェクトを構築すると、プログラムは正常に実行されます。これは、libc が使用する 1k の RAM が役に立たないという別のヒントです。array_initとPODタイプのデフォルトのコピー構築を維持しながらRAMオーバーヘッドを取り除く方法をさらに読んだり、説明したりできる人はいますか?
私のプロジェクトの .map ファイルの問題のあるエントリは次のとおりです。
*(vtable)
*(.data*)
.data._ZN3CDC4CoreI5MyCDCE11depInEmpty_E
0x10000000 0x1 ./src/Main.o
0x10000000 CDC::Core<MyCDC>::depInEmpty_
*fill* 0x10000001 0x3 00
.data.SystemFrequency
0x10000004 0x4 ./kvasir/system_LPC17xx.o
0x10000004 SystemFrequency
.data.impure_data
0x10000008 0x428 c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-impure.o)
.data 0x10000430 0x4 c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7-m\crtbegin.o
0x10000430 __dso_handle
0x10000434 . = ALIGN (0x4)
0x10000434 _edata = .
.jcr 0x10000434 0x0 load address 0x00003ee8
.jcr 0x10000434 0x0 c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7-m\crtbegin.o
.bss 0x10000434 0x1600 load address 0x00003ee8
0x10000434 _bss = .
*(.bss*)
.bss.inBuf 0x10000434 0x34 ./src/Main.o
0x10000434 inBuf
アップデート
コードを 1 行ずつ調べた後、修正が見つかりました。クラスの 1 つで空のデストラクタが定義されていました。
~MyClass(){}
コメントアウトすると、1KのRAMが削除されました。誰でも理由を教えてもらえますか?