GNU Arm Embedded Toolchain

Newlib RAM usage

Asked by Chri

Hello,

I work with GNU ARM for C and C++. Newlib is used for standard library, is this true? To reduce RAM and Flash usage, I added
--specs=nano.specs
and to reduce unused things
-Wl,--gc-section
to my linker options. Still the lib uses about 1kb RAM, if I do not even use it. This is quite much for embedded systems.

Creating a map file, I could see what data uses the space. It is .data.impure_data with 0x428 = 1064 bytes. Can this be reduced?

I just noticed, adding -nostartfiles to linker options removes this data. My startup file calls __libc_init_array() if C++ is enabled. Is it safe, to call this function and add -nostartfiles?

Anyway, why does this impure data require 1kB and what is it used for?

Thanks in advance!

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
chengbin
Solved:
Last query:
Last reply:
Revision history for this message
Chri (christian-motz-6) said : 		#1

I tested some more with -nostartfiles.

Adding this option and using a global class object, gives me an linker error.
undefined reference to `__dso_handle'

Now I know why I did not add this option. Quite tricky at all, to make C++ work.

Revision history for this message
chengbin (can-finner) said : 		#2

Hi,
Interesting, I am wondering why .data.impure_data uses 0x428 bytes. For my simple program:
#include <stdio.h>
#include <stdlib.h>

int a = 10;
int main(void)
{
    fprintf(stdout, "hello%d\n", a);

    return 0;
}
Compiled with below command line:
./arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -specs=nano.specs -specs=rdimon.specs main.c -lc -lrdimon -lc -o main.exe -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,-Map,a.map

It only uses about 0x64 bytes as in a.map:
 .data.impure_data
                0x00011500 0x64

May be you should recheck this issue firstly.
Hoping this can help.

Revision history for this message
Chri (christian-motz-6) said : 		#3

You are right, I can reproduce this.

If I use your command line and my linker script also a minimalistic main.cpp with a class and a global object does not use more data.impure.data

So there must be something with my compile and link flags. I check that and report back here.

Revision history for this message
Best chengbin (can-finner) said : 		#4

One note, you should use arm-none-eabi-gcc/g++ to link the final binary. The option "-specs=nano.specs" is actually a gcc/g++ one, rather than arm-none-eabi-ld's.

Thanks

Revision history for this message
Chri (christian-motz-6) said : 		#5

Does it have a special meaning that you write -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,-Map,a.map after the output -o main.exe and the -lxxx before the output?

Revision history for this message
chengbin (can-finner) said : 		#6

No special meaning here.

Thanks.

Revision history for this message
Chri (christian-motz-6) said : 		#7

Thanks!

Now I found the problem.

My makefile added -specs=nano.specs -specs=rdimon.specs for c++ compilation but not for linking. Seems this is the problem. Now x64 = 100 bytes is much better, this reduced basic ram usage about 90% to 1kb.

One more question: I found some other link options like -lnosys -lstdc++
Do you know where I find them documented?

Revision history for this message
chengbin (can-finner) said : 		#8

Glad to hear that.
As for "-lnosys", this is an option linking libnosys, which is a specific newlib library. You may refer to Newlib's document.
As for "-lstdc++", this stands for the standard c++ library, libstdc++.a specifically in GNU tool chain, and you need to refer to GNU documents like gcc manual.

Revision history for this message
Chri (christian-motz-6) said : 		#9

Thanks chengbin, that solved my question.