使用Cortex-M3的lpcxpresso:什么是libc.a(lib_a- impureo .o)，为什么要使用1k内存?

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.

我希望这不是针对特定领域的。我想知道为什么libc。a是用我在芯片上的8K内存中的1K。

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?

我不知道我使用libc的任何方式，除了它调用array_init中的全局对象的构造函数。据我所知，我认为它也涉及到默认的复制构造。我使用池分配，所以没有堆相关的东西(我确实使用了新布局，但这并不会导致libc在我知道的情况下使用ram)。如果我完全不使用这个库，并使用新的布局来构造我的所有全局对象，我的程序运行良好，这是另一个提示，libc使用的1k内存是无用的。谁能指出我可以继续阅读或者解释我如何保持array_init和默认的POD类型的构建，但是要清除内存开销?

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

这是我项目的.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

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?

注释去掉了1K内存。有人能告诉我为什么吗?

2 个解决方案

#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

这不是你的问题的直接解决方法，但可能是一个线索。冒号数据部分是库的可重入支持的一部分。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.

我想知道，如果这个部分消失了，那么您是否用- ffuncsection -fdata节来重建库?这听起来像是你从图书馆里拨出的珍贵资料，所以这可能是有效的。否则，你可能会被困在newlib上，或者只是借用你真正想要的东西。

#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.

在阅读了一些newLib代码之后，我觉得这是由一些正在加载的多线程程序引起的。我通过不声明任何非默认析构函数来解决这个问题。我已经读到，newLib nano将解决这个问题，但是我还没有测试，因为我的IDE并没有支持它。