Nano lib 2.1 much bigger image than 1.0

Asked by emblocks

Hi,

I'm busy with a new release of EmBlocks and I just updated the toolchain. I moved from nano-lib 1.0 to 2.1 and I notice a significant image increase.

Nanolib 1.0
Prog 9304
data 540
BSS 228

Nanolib 2.1
Prog 11736
data 1720
BSS 276

This is with the exact the same toolchain and options, only a nano lib difference.
Is this increase explainable?

Thanks

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
emblocks
Solved:
Last query:
Last reply:
Revision history for this message
emblocks (gnugcc) said :
#1

Update:

It has something to do with malloc. I get those functions in ver 2.1 which I did have at 1.0:

 .data.__malloc_av_
                0x20000254 0x408 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-mallocr.o)
                0x20000254 __malloc_av_
 .data.__malloc_trim_threshold
                0x2000065c 0x4 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-mallocr.o)
                0x2000065c __malloc_trim_threshold
 .data.__malloc_sbrk_base
                0x20000660 0x4 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-mallocr.o)
                0x20000660 __malloc_sbrk_base
 .data.lc_ctype_charset
                0x20000664 0x20 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-locale.o)
 .data.__mb_cur_max
                0x20000684 0x4 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-locale.o)
                0x20000684 __mb_cur_max
 .data.__wctomb
                0x20000688 0x4 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv6-m\libc_n.a(lib_a-wctomb_r.o)
                0x20000688 __wctomb

Revision history for this message
emblocks (gnugcc) said :
#2

I found it. I needed some extra switches on the build line.

Revision history for this message
Uwe Bonnes (bon) said :
#3

Please tell what extra switches you needed. This may help others with a similar problem.

Revision history for this message
emblocks (gnugcc) said :
#4

$SRCDIR/$NEWLIB_NANO/configure \
    $NEWLIB_CONFIG_OPTS \
    --target=$TARGET \
    --prefix=$BUILDDIR_NATIVE/target-libs \
    --disable-newlib-supplied-syscalls \
    --enable-newlib-reent-small \
    --disable-newlib-fvwrite-in-streamio \
    --disable-newlib-fseek-optimization \
    --disable-newlib-wide-orient \
    --enable-newlib-nano-malloc \
    --disable-newlib-unbuf-stream-opt \
    --enable-lite-exit \
    --enable-newlib-global-atexit \
    --disable-nls

source: build_toolchain.sh from the 4.8 download

Revision history for this message
emblocks (gnugcc) said :
#5

The nano 1.0 was build with:

$SRCDIR/$NEWLIB_NANO/configure \
    $NEWLIB_CONFIG_OPTS \
    --target=$TARGET \
    --prefix=$BUILDDIR_NATIVE/target-libs \
    --disable-newlib-supplied-syscalls \
    --enable-newlib-reent-small \
    --disable-nls

I notice that the nano 2.1 image is for small projects still a bit larger, but for larger projects a bit smaller.

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

Yes, I tuned nano lib a little making it easier to upstream, this might affect the code size. As you found, the size should be on the same level.

Thanks,
bin

Revision history for this message
Maxime Vincent (maximevince) said :
#7

Wow.. This should be documented somewhere. At least in the release notes.

How can I get my cortex-m0 builds to result in approx. the same size again?
A new object (locale.o) has been linked, which uses more than 350 additional bytes of RAM!

Revision history for this message
Maxime Vincent (maximevince) said :
#8

How is this solved?
Even with 6.0 the __global_locale is still there, eating >350 bytes of RAM!
Any way to remove locale.o from the linking?