GCC rules.ld heap assignment

[woodstock]

As a result of Subversion Revision 8280, builds for the STM32F407 using GCC are excessively large.
Using the RT-STM32F407-DISCOVERY example project (unmodified) and the latest trunk code, the program compiles to 158240 bytes. By reversing the changes made to os/common/ports/ARM/ARMCMx/compilers/GCC/rules.ld in that commit the compiled size goes back down to 32144.
Similarly, for another project using a STM32F103x8 it compiles to 46698 bytes with the heap assignment linker script and 34090 bytes without. Is this expected behaviour?

On another note, the STM43F103x8 devices are not currently supported by the HAL macros. These devices are Medium Density so it works fine to use the STM32F103xB definition, but I just thought I'd let you know anyway. Not a huge priority.

[Giovanni]

Hi,

Compiling the demo this is what I get:

Code: Select all

   text      data       bss       dec       hex   filename
  26716       632    130892    158240     26a20   build/ch.elf

Going into details:

Code: Select all

Idx Name          Size      VMA       LMA       File off  Algn
  0 startup       000001c0  08000000  08000000  00008000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000685c  080001c0  080001c0  000081c0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .textalign    00000004  08006a1c  08006a1c  0000ea1c  2**0
                  ALLOC
  3 .mstack       00000400  20000000  20000000  00018000  2**0
                  ALLOC
  4 .pstack       00000400  20000400  20000400  00018000  2**0
                  ALLOC
  5 .data         000000b8  20000800  08006a20  00010800  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .bss          00000ab8  200008b8  08006ad8  000108b8  2**3
                  ALLOC
  7 .ram0         00000000  20001370  20001370  000108b8  2**2
                  CONTENTS
  8 .ram1         00000000  20000000  20000000  000108b8  2**2
                  CONTENTS
  9 .ram2         00000000  2001c000  2001c000  000108b8  2**2
                  CONTENTS
 10 .ram3         00000000  00000000  00000000  000108b8  2**2
                  CONTENTS
 11 .ram4         00000000  10000000  10000000  000108b8  2**2
                  CONTENTS
 12 .ram5         00000000  40024000  40024000  000108b8  2**2
                  CONTENTS
 13 .ram6         00000000  00000000  00000000  000108b8  2**2
                  CONTENTS
 14 .ram7         00000000  00000000  00000000  000108b8  2**2
                  CONTENTS
 15 .heap         0001ec90  20001370  20001370  00018000  2**0
                  ALLOC

The code size is the same. The difference is caused by how the heap is allocated. The old method was to use all RAM not allocated, the new method is to allocate the remaining RAM for the heap into a specific ".heap" section. This means that now apparently the RAM is always all used.

Giovanni

[woodstock]

Ok. Thank you for the clarification.