Code size increase

Asked by Mauricio

I've changed from gcc-arm-none-eabi-5_3-2016q1-20160330-win32 to gcc-arm-none-eabi-5_4-2016q3-20160926-win32 and noticed a increase in the code size and ram usage.

With 5.3:
build/main.elf :
section size addr
.text 0xb68c 0x8000000
.rodata 0x1d08 0x800b698
.data 0xa8 0x20000000
.bss 0x1198 0x200000a8
Size: 54344 bytes

With 5.4:
Size after:
build/main.elf :
section size addr
.text 0xb6f0 0x8000000
.rodata 0x1e10 0x800b700
.data 0x1d8 0x20000000
.bss 0x1198 0x200001d8
Size: 55016 bytes

Switches:

-c
-mthumb
-I.
-mcpu=cortex-m4
-mfloat-abi=softfp
-mfpu=fpv4-sp-d16
-gdwarf-2
-Os
-funsigned-char
-funsigned-bitfields
-fshort-enums
-fverbose-asm
-fdata-sections
-ffunction-sections
-Wall
-mno-unaligned-access
-pedantic
-Wshadow
-Wno-variadic-macros
-Wpointer-arith
-Wcast-align
-Wcast-qual
-Wextra
-Wno-write-strings
-Wunreachable-code
-Wno-format
-Wa,-adhlns=build/hostcomm.lst
-MMD
-MP
-MF build/dep/hostcomm.o.d
-fno-rtti
-fno-exceptions
-std=gnu++11

Is there anything that can help me with the code size? Or is ti something that i'll have to live with? Is there any big problem about remain using the 5.3 release?

Thanks, Mauricio

Question information

Language:
English Edit question
Status:
Expired
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#1

Hi Mauricio,

Without a preprocessed C file to reproduce the issue it is impossible to tell you what is the source of the problem. You could try using -Wl,--gc-sections when linking (assuming you link with GCC) and see if that helps.

Best regards.

Revision history for this message
john (jkovach) said :
#2

You can just keep using the version you are used to. I am using 4.8 and not planning to upgrade any time soon. Of course, you can read the release notes to see if there are new features or bug fixes that might compel you to upgrade. Otherwise, I think that a toolchain upgrade is more trouble than it's worth.
Just my opinion, though.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#3

Please note that more bugs get fixed than what is written in the release note. For each update release we merge all the changes from the stable FSF GCC branch which contain many bug fixes. We only list the ones that we fixed ourselves or for which a question or bug was created on Launchpad.

Best regards.

Revision history for this message
Mauricio (mscaff) said :
#4

Hi, Thomas.

I already have those flags set in the linker.

My linker flags:

-u _printf_float
-Wl,-Map=build/main.map,--cref,-gc-sections
-lc
-mcpu=cortex-m4
-lm
-lgcc
-lstdc++
-flto
--specs=nano.specs

What exactly do you need in the pre processed files? Just the header?

   1 .syntax unified
   2 .cpu cortex-m4
   3 .eabi_attribute 27, 1 @ Tag_ABI_HardFP_use
   4 .fpu fpv4-sp-d16
   5 .eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
   6 .eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
   7 .eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
   8 .eabi_attribute 24, 1 @ Tag_ABI_align8_needed
   9 .eabi_attribute 25, 1 @ Tag_ABI_align8_preserved
  10 .eabi_attribute 26, 1 @ Tag_ABI_enum_size
  11 .eabi_attribute 30, 4 @ Tag_ABI_optimization_goals
  12 .eabi_attribute 34, 0 @ Tag_CPU_unaligned_access
  13 .eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t
  14 .file "1wire.cpp"
  15 @ GNU C++11 (GNU Tools for ARM Embedded Processors) version 5.3.1 20160307 (release) [ARM/embedded-
  16 @ compiled by GNU C version 4.7.4, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
  17 @ GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  18 @ options passed: -I . -I bitmaps/ -I ../common//fonts/ -I include/
  19 @ -I ../common//include/
  20 @ -I ../common//../lib/STM32Cube_FW_L4_V1.2.0/Drivers/CMSIS/Device/ST/STM32L4xx/Include/
  21 @ -I ../common//../lib/STM32Cube_FW_L4_V1.2.0/Drivers/CMSIS/Include/
  22 @ -I ../common//../lib/STM32Cube_FW_L4_V1.2.0/Drivers/STM32L4xx_HAL_Driver/Inc
  23 @ -imultilib armv7e-m/softfp
  24 @ -iprefix c:\prg\gcc-arm-none-eabi-5_3-2016q1-20160330-win32\bin\../lib/gcc/arm-none-eabi/5.3.1/
  25 @ -isysroot c:\prg\gcc-arm-none-eabi-5_3-2016q1-20160330-win32\bin\../arm-none-eabi
  26 @ -MMD build/1wire.d -MF build/dep/1wire.o.d -MP -MQ build/1wire.o
  27 @ -D__USES_INITFINI__ -D THUMB -D ROM_RUN -D STM32L476xC -D STM32L476xC
  28 @ -D _DEFAULT -D HSE_VALUE=0 -D M4F -D STM32L476xx -D __STM32L4
  29 @ -D __BUILD_NUMBER=58 -D __ARM__ -D VECT_TAB_FLASH ../common//1wire.cpp
  30 @ -mthumb -mcpu=cortex-m4 -mfloat-abi=softfp -mfpu=fpv4-sp-d16
  31 @ -mno-unaligned-access -auxbase-strip build/1wire.o -gdwarf-2 -Os -Wall
  32 @ -Wpedantic -Wshadow -Wno-variadic-macros -Wpointer-arith -Wcast-align
  33 @ -Wcast-qual -Wextra -Wno-write-strings -Wformat=0 -std=gnu++11
  34 @ -funsigned-char -funsigned-bitfields -fshort-enums -fverbose-asm
  35 @ -fdata-sections -ffunction-sections -fno-rtti -fno-exceptions
  36 @ options enabled: -faggressive-loop-optimizations -falign-functions
  37 @ -falign-jumps -falign-labels -falign-loops -fauto-inc-dec
  38 @ -fbranch-count-reg -fcaller-saves -fchkp-check-incomplete-type
  39 @ -fchkp-check-read -fchkp-check-write -fchkp-instrument-calls
  40 @ -fchkp-narrow-bounds -fchkp-optimize -fchkp-store-bounds
  41 @ -fchkp-use-static-bounds -fchkp-use-static-const-bounds
  42 @ -fchkp-use-wrappers -fcombine-stack-adjustments -fcommon -fcompare-elim
  43 @ -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdata-sections
  44 @ -fdefer-pop -fdelete-null-pointer-checks -fdevirtualize
  45 @ -fdevirtualize-speculatively -fdwarf2-cfi-asm -fearly-inlining
  46 @ -feliminate-unused-debug-types -fexpensive-optimizations
  47 @ -fforward-propagate -ffunction-cse -ffunction-sections -fgcse -fgcse-lm
  48 @ -fgnu-runtime -fgnu-unique -fguess-branch-probability
  49 @ -fhoist-adjacent-loads -fident -fif-conversion -fif-conversion2
  50 @ -findirect-inlining -finline -finline-atomics -finline-functions
  51 @ -finline-functions-called-once -finline-small-functions -fipa-cp
  52 @ -fipa-cp-alignment -fipa-icf -fipa-icf-functions -fipa-icf-variables
  53 @ -fipa-profile -fipa-pure-const -fipa-ra -fipa-reference -fipa-sra
  54 @ -fira-hoist-pressure -fira-share-save-slots -fira-share-spill-slots
  55 @ -fisolate-erroneous-paths-dereference -fivopts -fkeep-static-consts
  56 @ -fleading-underscore -flifetime-dse -flra-remat -flto-odr-type-merging
  57 @ -fmath-errno -fmerge-constants -fmerge-debug-strings
  58 @ -fmove-loop-invariants -fomit-frame-pointer -foptimize-sibling-calls
  59 @ -fpartial-inlining -fpeephole -fpeephole2 -fprefetch-loop-arrays
  60 @ -freg-struct-return -freorder-blocks -freorder-functions
  61 @ -frerun-cse-after-loop -fsched-critical-path-heuristic
  62 @ -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
  63 @ -fsched-last-insn-heuristic -fsched-pressure -fsched-rank-heuristic
  64 @ -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep
  65 @ -fschedule-insns2 -fsection-anchors -fsemantic-interposition
  66 @ -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types
  67 @ -fssa-phiopt -fstdarg-opt -fstrict-aliasing -fstrict-overflow
  68 @ -fstrict-volatile-bitfields -fsync-libcalls -fthread-jumps
  69 @ -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce
  70 @ -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
  71 @ -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts
  72 @ -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-if-convert
  73 @ -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
  74 @ -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta
  75 @ -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slsr -ftree-sra
  76 @ -ftree-switch-conversion -ftree-tail-merge -ftree-ter -ftree-vrp
  77 @ -funit-at-a-time -fvar-tracking -fvar-tracking-assignments -fverbose-asm
  78 @ -fzero-initialized-in-bss -masm-syntax-unified -mlittle-endian
  79 @ -mpic-data-is-text-relative -msched-prolog -mthumb
  80 @ -mvectorize-with-neon-quad
  81

Thanks, Mauricio

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#5

Hi Mauricio,

I meant that we need the source with necessary header files to reproduce the issue. You can build with -save-temps which will create a .i file where all headers have been inline. We need this file and with the command line you gave us we can hopefully reproduce your issue. I cannot promise anything as bug fixes take priority and sometimes there is nothing we can do but we'll hopefully be able to have a look.

Best regards.

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

I have the same issue here.
Code size and RAM are super important on Cortex-M0-size devices...

There is no mention in the release notes of any possible code size increase.
Yet my -Os optimized build just increased by >350 bytes of RAM!

Please give some insights on this. This is a blocking issue for me to upgrade to 5.4.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :
#7

Hi Maxime,

We cannot debug this without a testcase for us to reproduce. If you cannot provide code, you could start by doing arm-none-eabi-nm -S <yourapp> and compare before and after as to where size has increased. Hopefully the size increase is in libraries and you don't have to send us any code. If that is so, please tell us what library and what symbol.

Best regards.

Revision history for this message
Mauricio (mscaff) said :
#8

Hi, Thomas.
I did as you told me.
Those are the differences I found. These symbols are only defined on the 5.4 version and account for almost all the space used in the new code.

5.3:
T __aeabi_uldivmod

00000008 T _localeconv_r
000000a8 T _malloc_r

5.4:
T __aeabi_uldivmod
00000024 T __ascii_mbtowc
0000001a T __ascii_wctomb

0000016c D __global_locale

00000002 T __malloc_lock
00000002 T __malloc_unlock

00000101 R _ctype_

0000001c T _localeconv_r
000000bc T _malloc_r

So, it seems the main problem about the code size increase is the inclusion of 6 new symbols: __ascii_mbtowc
__ascii_wctomb
__global_locale
_ctype_

that account for 683 bytes

Thanks, Mauricio

Revision history for this message
Mauricio (mscaff) said :
#9

I found what was creating the increase in the file size. The code i was testing uses float point printing.

LDFLAGS += -u _printf_float

After removing it (that is the case of most of my codes) both 5.3 and 5.4 creates code with the same size (44768)

I still don't know how to avoid the file size increase if I need to use float point print, but this is a much smaller problem.

Thanks, Mauricio

Revision history for this message
Launchpad Janitor (janitor) said :
#10

This question was expired because it remained in the 'Open' state without activity for the last 15 days.