Successfully build Discovery4 with GCC 5.4.1

[josesimoes]

GNU ARM Embedded 5-2016-q2-update with GCC 5.4.1 was released last week.
After a few tweaks I've successfully build a NETMF image.

Image size comparison

• GCC 4.9
  Tinybooter.bin 41812B
  ER_FLASH 322525B
• GCC 5.3.2 with newlib nano and default compile settings
  Tinybooter.bin 42700B
  ER_FLASH 308380B
• GCC 5.3.2 with newlib nano and C11 compile settings
  Tinybooter.bin 42220B
  ER_FLASH 305276B

[smaillet-ms]

Not bad. 😄
TinyBooter is oddly a bit larger in 5.3.2 with newlib nano... That's unexpected, any idea what is making it bigger?

Is that C11 or C++11? - There's a difference, especially since most of NETMF is actually C++ code (though most of it doesn't really use much of the C++ language at this point) Never mind, PR #475 shows both are set (Although it applies globally to all projects and solutions so that needs to be made opt-in before it can be merged into the repo)

[piwi1263]

I just can confirm that after applying the changes from José a release build for Tinybooter and the TinyClr deployed succesfully to the STM32F429IDISCOVERY as well.

• GCC 5.4.1
• Tinybooter.bin -> 42572B
• ER_FLASH -> 303868B

[cw2]

@smaillet-ms The extra code in 5.4.1 comes from newlib-nano malloc locking, CRT _init and _fini functions and minor differences in generated assembly instructions and alignments. However, the majority is endian swapping routines, which are not present in 4.9 build, namely (symbols from Tinybooter.dump):

_Z10SwapEndianj
_ZN10WP_Message10SwapEndianEv
_ZN13Loader_Engine10SwapEndianEP10WP_MessagePvib
_ZN13Loader_Engine17SwapEndianPatternERPhjj

which is very weird, because they are conditionally compiled #ifdef BIG_ENDIAN and should not even be there. This seems to be a problem of GCC 5.4.1, because those functions are not present in any of the older builds (4.9.3, 5.2.1, 5.3.1).

[smaillet-ms]

Hmmm, smells like something in the build is incorrectly setting the wrong ENDIAN macro for the compiler... If so that would be a bug lurking. I'd be very surprised if the compiler itself was getting that wrong and generating the code AND the linker wasn't removing it as unused...

[cw2]

The strange thing is that as far as I can tell, there is no BIG_ENDIAN symbol used anywhere - the msbuild.log file contains only -DLITTLE_ENDIAN parameters, which are correct.

[smaillet-ms]

That's very odd... Does the linker generate any sort of dependency/call tree that could be analyzed to identify what is bringing in those APIs. Is it possible one of the binary libs (Crypto lib perhaps) is the wrong one? Though, even then they should have been conditionally compiled out...

[cw2]

Attached is a zip archive with STM32F4DISCOVERY TinyBooter build output files produced by both GCC 5.3.1 and 5.4.1; using latest source code, no crypto libs and with removed nosys.specs linker option in tools\Targets\Microsoft.Spot.system.gcc.targets to fix the missing symbol error.

BuildOutput-TinyBooter-GCC-5.3.1-5.4.1.zip

See the differences between TinyBooter.map files...

[mbyamukama]

Could you kindly share the whole build output including the flash and config files? For those of us who are just testing...and not building!

[josesimoes]

@cw2 apart from versions and addresses changing I can spot these:

• inclusion of lib_a-nano-freer.o with __malloc_lock
• Loader_Engine::SwapDebuggingValue
• SwapEndian
• inclusion of lib_a-mlock.o

Anything else I'm missing?

[josesimoes]

@cw2 I wanted to compare the map file I get with the discovery4 build in PR #475 and the one you've uploaded above. To do that I cleared the BuildOutput folder and run the build. I don't get any SwapEndian on this build.... I did the above twice, just to be sure of it.
That SwapEndian/BIG_ENDIAN that is getting into your output must come form somewhere else.

[cw2]

@josesimoes The strange thing is that these functions are present only in GCC 5.4.1 build, not 5.3.1 which was performed using the same input. I would understand SwapEndian symbol, there were some changes related to inlining in 5.4.1 vs. 5.3.1, but I don't know why the other (Loader_Engine::, WP_Message::) functions are present. I have not had enough time to investigate this further, as long as these functions are not called I am fine. Perhaps there is something wrong in my build environment...

[josesimoes]

@cw2 understood. Guess we need another volunteer to run a build and check if those show on their output or not... 😉

[josesimoes]

@cw2 after getting a clean machine and install I can confirm that I'm seeing this BIG_ENDIAN stuff showing up on the build output.
I've opened #481 and reported a bug with GCC toolchain.

[cw2]

Thanks @josesimoes . I was able to reproduce the problem on a completely clean system, so it seems to be GCC 5.4.1 bug.