[SOLVED] [libmaple F4] Very large sketch size when using malloc()

[SOLUTION IN THIS POST] http://www.stm32duino.com/viewtopic.php … 093#p33153

I just noticed while testing some issue with Sloeber from another thread, that compiling this sketch from Rick produces about 13KB in a Maple mini, but over 60KB in the Generic F4 using latest Steve’s repo.
But I could only test in Sloeber because both my installs of Arduino 1.6.1 and 1.8.3 fail to compile for F4 with different errors, I think the path is too long or something. So while I try to get that solved, would appreciate if someone else can try to compile this sketch with Arduino IDE and see what’s the code size.
Link to post with the test code:
viewtopic.php?f=41&t=2434&start=50#p33019

The problem is probably the same one discussed here:

http://www.stm32duino.com/viewtopic.php?f=3&t=1904

Changes to platform.txt were nixed because some people use FreeRTOS

https://github.com/rogerclarkmelbourne/ … issues/296

With Steve repo and arm gcc 6

Maple Mini:
Sketch uses 17524 bytes (15%) of program storage space. Maximum is 110592 bytes.
Global variables use 3976 bytes (22%) of dynamic memory, leaving 13432 bytes for local variables. Maximum is 17408 bytes.

Thank you guys, at least that confirms is not just Sloeber.
The F4 recipe still includes –whole-archive, which may be having something to do with USB being included even if not used, but there is more than the USB code, so I did a test adding Serial.begin and Serial.print and added about 5-7KB more.
Wehn i get back home I will check the .map file to try to see what else is being pulled in.

@Rick, since the fix in that thread was not added to the core, the F1 is not using it and the same sketch only takes 13KB or so, there must be something else affecting the size being so large on F4.
I’ll try to do some more tests when I’m back home, and hopefully get my Arduino IDE working again.

@Frederic, did you try compiling the same with the official STM core in Arduino? if so, what is the code size?

With Arduino_Core_STM32 and arm gcc 6 (note: with -Os flag and -fno-threadsafe-statics for c and cpp):

For Disco F407G:
Sketch uses 11092 bytes (1%) of program storage space. Maximum is 1048576 bytes.
Global variables use 2552 bytes (1%) of dynamic memory, leaving 194056 bytes for local variables. Maximum is 196608 bytes.

From my .map file, some of the largest chunks are these:
.text 0x080044d8 0x5784 c:/sloeber/arduinoplugin/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m\libstdc++.a(cp-demangle.o)
0x08009b7c __cxa_demangle


Seems libstdc++ is added by sloeber in the link option. Is it really needed?

I did some more testing.
Commenting out the new() call, brings the sketch size to 12KB
//dumb = new dumbclass;

The line with malloc() does not have a significant impact, this one:
buffer = (char *)malloc(1024);

When checking the .map file I see new is being pulled from stdc++, so that’s what’s pulling that library. Then did a search in the repo for new, since I remember there was an implementation in the core, and found out it was only in the F1 repo, Roger added it a while back:
https://github.com/rogerclarkmelbourne/ … 2a824d80b7

Adding that file to the F4 resolves the issue when compiling it in Sloeber, but my Arduino IDE is still not working so can’t test on it.

Would someone be able to test and confirm it solves it in the Arduino IDE also? I haven’t had time to troubleshoot the IDE problems since I have instead used the time in troubleshooting this size issue, since it affected both IDEs anyway.

I’ve added new.cpp then for generic F407V:
Sketch uses 14052 bytes (2%) of program storage space. Maximum is 514288 bytes.
Global variables use 7384 bytes (5%) of dynamic memory, leaving 123688 bytes for local variables. Maximum is 131072 bytes.

Arduino IDE 1.6.14 and Steve’s older repo (April 15th), variant Generic_f407V, Rick’s test above (LED commented out), no fix, no patch:
Linking everything together...
"C:\Users\pito\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++" -Os -Wl,--gc-sections -mcpu=cortex-m4 "-TC:\Users\pito\MyCode\Arduino\hardware\Arduino_STM32SerBuff\STM32F4SS\variants\generic_f407v/ld/jtag.ld" "-Wl,-Map,C:\Users\pito\AppData\Local\Temp\arduino_build_423602/RICK_TEST.ino.map" "-LC:\Users\pito\MyCode\Arduino\hardware\Arduino_STM32SerBuff\STM32F4SS\variants\generic_f407v/ld" -o "C:\Users\pito\AppData\Local\Temp\arduino_build_423602/RICK_TEST.ino.elf" "-LC:\Users\pito\AppData\Local\Temp\arduino_build_423602" -lm -lgcc -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\sketch\RICK_TEST.ino.cpp.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\core\stm32_isrs.S.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\core\stm32_vector_table.S.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\core\wirish\start.S.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\core\wirish\start_c.c.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602\core\generic_f407v.cpp.o" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602/core\core.a" -Wl,--end-group
c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m\libnosys.a(sbrk.o): In function `_sbrk':

sbrk.c:(.text._sbrk+0x30): warning: undefined reference to `end'

"C:\Users\pito\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-objcopy" -O binary "C:\Users\pito\AppData\Local\Temp\arduino_build_423602/RICK_TEST.ino.elf" "C:\Users\pito\AppData\Local\Temp\arduino_build_423602/RICK_TEST.ino.bin"

Sketch uses 70,464 bytes (13%) of program storage space. Maximum is 514,288 bytes.
Global variables use 15,568 bytes of dynamic memory.

[victor_pv – Fri Aug 18, 2017 2:18 pm] –
When checking the .map file I see new is being pulled from stdc++, so that’s what’s pulling that library. Then did a search in the repo for new, since I remember there was an implementation in the core, and found out it was only in the F1 repo, Roger added it a while back:
https://github.com/rogerclarkmelbourne/ … 2a824d80b7

If you are going to be adding things …. this might be a nice addition to new.cpp:

inline void * operator new( size_t sz, void * here )
{
return here;
}

inline void * operator new[]( size_t sz, void * here )
{
return here;
}


Rick, probably we should add it to the F1 too.
I’ll add the functions to the F1 and F4 new.cpp files and send PRs.

EDIT:
And just guessing in the example above, this:
dumppter;
should actually be:
dump_ptr;

Rick, did you test it successfully?
I can’t use those operators, even with the libstd++ version (remove new.cpp):
..\malloc_test.ino:41:33: error: no matching function for call to 'operator new(sizetype, unsigned int [12])'
dumb_ptr = new(memory_buffer) dumbclass;
^
..\malloc_test.ino:41:33: note: candidate is:
<built-in>:0:0: note: void* operator new(unsigned int)
<built-in>:0:0: note: candidate expects 1 argument, 2 provided

Sorry if you include that code in new.cpp .. the “inline” probably got it optimized out. I had tested that code with the placement new inline functions in the .ino file.

The best thing would be to put those functions into a “new.h” and have Arduino.h include “new.h” Something to do another day. Forget I ever mentioned ; )

I thought the libstdc++ would have the declaration like it does for other ‘new’ operators. Surprisingly I see the functions in file “new” within the GCC folders but not even those compiled and gave the error above.
Well we will work on that at some point, at the moment I’ll send the PR to just add new.cpp to the F4 so it doesn’t pull libstdc++, then we can look at adding this as a separate PR.

If a person is going to use C++ new with embedded chips, they might do themselves well to understand about memory pools and custom new for classes.

Scott Meyers C++ book has some great advice there.

google search: Scott Meyers effective c++ pool filetype:pdf

I’ve got Effective C++ second edition in a shelf half way thru…
There is a lot of advise about classes, way more than my brain cares to remember…