Code size increase from version 2.0.11 to 2.2.0

Follow

zelea2

• March 07, 2012 17:57

I have a STM32 project which compiles in version 2.0.11 to a size of 32308 bytes. The same project compiles in version 2.2.0 to 34452 bytes. The code is optimized for size and is generated for THUMB Release with no debug info and has unused symbols stripped away. This 7% size increase just made my 32K flash overflow. Is this size increase related to the fact that I am using an evaluation license for version 2.2.0 or is the gcc in this version just generating worse size optimized code?

0

• 

  Markus

  • March 12, 2012 06:45

  Hello,

   

  I checked it with my small project, I get

  84352 Byte Flash usage with 2.1.1 and

  81576 Byte Flash usage with 2.2. Both with Optimization Level 1.

  So, no increase of Flash usage, only the RAM usage is 8 Bytes higher.

   

  Greetings

   

  Markus

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 12, 2012 12:23

  I suspect that printf is being linked in by default. Use

  Tools | Options | Building Options

  to set the defaults to include debugIO/printf/scanf OR set the project properties to the values you require.

  Regards

  Michael

  0

  Comment actions Permalink
• 

  zelea2

  • March 12, 2012 14:51

  There is no significant size difference between 2.1.x and 2.2.0 but the 2.0.11 produces smaller code. My project uses printf (just integer) and no scanf. So the size increase can also come from the libraries. I'll have a look at the actual numbers later.

  0

  Comment actions Permalink
• 

  Andy Heilveil

  • May 01, 2012 14:55

  with 2.2 the library is managed differently and I got the whole of the c library included. To get rid of the unused functions I chagned project option/Build Options/enable Unused Symbol Removal to Yes.

  When I did that I then lost a bunch of stuff as the linker couldn't figure out that my interrupt handlers were used (I don't use Rowley's default startup files), and then it also dropped statically invoked C++ constructors. I added all those back in via -u command line options (which I had enough of to use the Linker Options/Additional Linker Options From File feature). I had to use the mangled name for the C++ functions, which I got via using nm on the 2.0.11 version of the elf.

  0

  Comment actions Permalink
• 

  Andy Heilveil

  • May 02, 2012 20:12

  my previous post still didn't have things totally correct. I had to update my ld file with the contents that are generated by a build in the new system and then all my static constructors and isr functions and the like were included without forcing the linker with -u's (except my vector table is named differently and I had to deal with just that one item).

  My previous post forced the constructors to exist, but statically called instances were not getting called.

  0

  Comment actions Permalink

Please sign in to leave a comment.