lpcxpresso与Cortex-M3：什么是libc.a（lib_a-impure.o）为什么它使用1k的ram？

Question

I hope this is not to domain specific. I would like to know why libc.a is using 1K of the 8K of ram that I have on chip.

I am not aware of any way that I am using libc other than it calling the constructors of my global objects in array_init. I think its involved in default copy construction too as far as I know. I use pool allocation so no heap related stuff (I do use placement new but that should not cause libc to use ram as far as I know). If I leave out the library completely and use placement new as a hack to construct all my global objects in main my program runs fine, this is another hint that the 1k of ram used by libc is useless. Can anyone point me to further reading or explain how I can keep array_init and default copy construction of POD types but get rid of the RAM overhead?

Here is the offending entry in the .map file of my project:

 *(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

Update

after going through my code line by line I found a fix, I had an empty destructor defined in one of my classes

~MyClass(){}

commenting that out removed the 1K of ram. Can anyone tell me why?

Answer 1

This isn't a direct solution to your problem, but perhaps a lead. The impure_data section is part of the library's reentrancy support. http://web.archive.org/web/20090106124055/http://venus.billgatliff.com/node/3

I wonder if you rebuild the library with -ffunction-sections -fdata-sections if that section goes away? It sounds like you call precious little from the library, so that may be effective. Otherwise, you might be stuck hacking on newlib or just borrowing the pieces you really want.

Answer 2

After reading a bit into the newLib code it seems to me that this is being caused by some multithreadding stuff being loaded. I solved the problem by not declaring any non default destructors. I have read that the newLib nano will solve this problem but I haven't tested because my IDE does not support it yet out of the box.