impure_data array eats my RAM

This toolchain uses newlib, whose size is big for mcu. 4.7 major release in
q4 2012 should do much better. We plan to reduce newlib code size in that
release.
On Jun 10, 2012 12:45 AM, "IgorKossak" <email address hidden>
wrote:

> Question #199930 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/199930
>
> Description changed to:
> Small project built with Linaro gcc-arm-none-eabi gives a .bss section
> about 1 kbytes more than the same project built with CodeSourcery's
> toolchain.
> A microcontroller has only 4 kilobytes of RAM, to allow to 1/4 of RAM to
> be spent for nothing.
> How to solve this problem?
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Hi IgorKossak,
I am not sure whether it is .bss section or the .data section that larger than CodeSourcery' build.
For our test programs, .bss section is not that larger than others.
If it is .data section, the most possible reason is that our toolchain uses newlib.

Either way, could you offer more information of your project, such as which library is used.
It will help us find the root cause and keep improving our tools in following releases.

Thanks very much.

Hi chengbin,
I made a mistake about the section of .bss, actually it is a section of .data
The result of building is:
CodeSourcery arm-2011.09-69-arm-none-eabi
section size addr
.isr_vector 0x10c 0x8000000
.text 0x37d4 0x800010c
.ARM.exidx 0x8 0x80038e0
.data 0xf8 0x20000000
.bss 0xb0c 0x200000f8
._usrstack 0x100 0x20000c04

Linaro gcc-arm-none-eabi-4_6-2012q1-20120316
section size addr
.isr_vector 0x10c 0x8000000
.text 0x380c 0x800010c
.ARM.exidx 0x8 0x8003918
.data 0x434 0x20000000
.bss 0xb0c 0x20000434
._usrstack 0x100 0x20000f40

Sourcery's datasheet is https://sourcery.mentor.com/GNUToolchain/release2032?@template=datasheet

In my C++ project I have only one one-byte initialised global variable. The rest is an impure_data array. In case of Linaro toolchain this array is much more.

Thank you.

Thanks very much for the details.
For .data section, it is because our toolchain uses newlib, which defines a large reent structure.
We are now working on the 4.7 major release, which should do much better.

Thanks again.

Could you shed some light on your plans regarding "minimizing" of newlib? Do you plan to do some code-base changes or just change compilation options?

Thx in advance for info!

FCh

Mainly by code change based on newlib. also built with -Os

That's interesting! Do you have any public repository that I could take a look at? Currently I'm fighting with size of newlib (more with RAM usage) and also have some ideas on shrinking it - for a start a 1kB stack buffer in __sbprintf() (called from _VFPRINTF_R() ) should be changed to dynamic one.

I was also looking at PDCLIB - that would be an interesting replacement of newlib's libc (but not libm).

Code expect to be included in 4.7 release in Q4 this year.

On Wed, Oct 10, 2012 at 6:35 PM, Freddie Chopin <
<email address hidden>> wrote:

> Question #199930 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/199930
>
> Freddie Chopin posted a new comment:
> That's interesting! Do you have any public repository that I could take
> a look at? Currently I'm fighting with size of newlib (more with RAM
> usage) and also have some ideas on shrinking it - for a start a 1kB
> stack buffer in __sbprintf() (called from _VFPRINTF_R() ) should be
> changed to dynamic one.
>
> I was also looking at PDCLIB - that would be an interesting replacement
> of newlib's libc (but not libm).
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Version 4.7 did not justify my expectations.

.data 0x430 0x20000000

 .data.impure_data
                0x20000008 0x428 c:/program files/gnu tools arm embedded/4.7 2012q4/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc.a(lib_a-impure.o)

Newlib nano resolves it. May you please try it following reader?
On Feb 2, 2013 9:01 PM, "IgorKossak" <email address hidden>
wrote:

> Question #199930 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/199930
>
> Status: Answered => Open
>
> IgorKossak is still having a problem:
> Version 4.7 did not justify my expectations.
>
> .data 0x430 0x20000000
>
> .data.impure_data
> 0x20000008 0x428 c:/program files/gnu tools arm
> embedded/4.7
> 2012q4/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc.a(lib_a-impure.o)
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

You could also try my compilation, which uses reent-small with normal newlib (and some other options) - this should reduce the size of impure data

http://www.freddiechopin.info/en/download/category/11-bleeding-edge-toolchain

I've also got 4.7 compiled, but not yet published.

Freddie, personally I don't recommend newlib with reent-small. It saves
static data but increases both text and dynamic data. Especially dynamic
data is increased more than static data saved. The reason is that malloc
allocates about 4k, when allocating dynamic impure_data.
On Feb 2, 2013 9:55 PM, "Freddie Chopin" <
<email address hidden>> wrote:

> Question #199930 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/199930
>
> Freddie Chopin proposed the following answer:
> You could also try my compilation, which uses reent-small with normal
> newlib (and some other options) - this should reduce the size of impure
> data
>
> http://www.freddiechopin.info/en/download/category/11-bleeding-edge-
> toolchain
>
> I've also got 4.7 compiled, but not yet published.
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

But wouldn't it actually be allocated only if needed? If that would be so in application that does not need impure data at all this should never allocate anything... Reent just just so monstrous that it's crazy [;

BTW - newlib-nano is compiled with reent-smal...

> But wouldn't it actually be allocated only if needed?
Yes, but it is needed almost every where. When ever you can any IO function it will be allocated. Say it in another way, it you don't need it, you probably even needn't link libc at all.

> BTW - newlib-nano is compiled with reent-small
Yes, but malloc in newlib-nano has almost no overhead, thus makes it appropriate for reent-small. Say it need about 400 bytes for reent-small's impure data, nano-malloc requests about the same size of heap space, where as newlib malloc ask for about 4K.

"Yes, but malloc in newlib-nano has almost no overhead, thus makes it appropriate for reent-small. Say it need about 400 bytes for reent-small's impure data, nano-malloc requests about the same size of heap space, where as newlib malloc ask for about 4K."

Even if malloc() really requests 4kB from sbrk it does not mean that it actually needs that for this single allocation (the rest of memory is kept for next uses) and the overhead is not that big... It's just that newlib's malloc() is said to be really efficient and tries to prevent memory fragmentation...

Hi,
I agree with you about that, but we try to support full spectrum of boards and some of them have very limited RAM resource.
For example, test programs with reent-small can't run on some of our boards.

Thanks.

It seems that this is fixed with the Q3 release for me too, reent structure size is much more palatable now with:
-D_REENT_SMALL -D_REENT_GLOBAL_ATEXIT

Thanks.

But the configuration of newlib in the new release is the same as always - regular newlib uses "large" reent and doesn't use global atexit... In newlib-nano the options that you mention are enabled, but - on the other hand - they have always been enabled for this variant...