Closed esden closed 11 years ago
Why do we occupy more space with more recent compiler??
Also if we merge this, that definitely needs to go into the readme and changelog, as it will break for quite a few people/cases.
OK, so I did some more investigation. The main source of size increase of luftboot was a change in libopencm3. It got fixed (libopencm3/libopencm3@8545d9d56581c6b6706684fd0a4ba903cf53c595) the issue was with the use of exit that was adding over 1.7kb of code to the binary. I also added a check to the makefile, that will try to detect if specs.nano are available, and use that parameter only then. This should prevent breakage.
Oh, so this was actually never a problem if you built luftboot from within paparazzi master, as the offending commit was not included there...
Did you test it without specs.nano? The _fini() stub doesn't create a problem then?
Yes I did test it without nano.specs. And no the _fini symbol does not cause problems, as we don't care about it in the bootloader, and it has precedence over the clibrary. Still I removed the definition again.
I think you are right, if the commit was never in paparazzi then it was not happening there. I just don't build the bootloader inside of paparazzi that is why I ran into the problem.
:-) Merged with 98dab2c95bca41a5e9ab1ae3f8621b0e76f99167
When compiling with the newest version of libopencm and gcc arm embedded, we were occupying more then the available 8kb of space reserved for the bootloader.
Changed the linker parameters to use the nano.specs setup so that the binary fits in the first sector of memory.
The use of nano.specs will break compilation on older (linaro for example) compilers that don't support that function.
As paparazzi is moving to use gcc-arm-embedded as it's default compiler this should not be an issue...
Please test it so we can merge it soon. :)