Sharing bootload functions with application code--Can optimization bite you?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have some bootloader code that I decided  to try to shrink by eliminating some  "dead code".  It was effectively "dead" since the associated functions were never called with a parameter value that would cause that code to be executed.

 

I checked the resulting program memory size and saw there was no reduction in size at all.  Apparently, the optimizing compiler was smart enough to realize the functions were never called with parameters set so that code would get executed and did the work I was doing manually.  Cool!  Maybe.

 

I was planning on having the application code use some of the bootloader functions via well known addresses and function pointers.  But, what if the compiler simplified the function's code based on what was needed for the code it could see at bootloader compilation time, but the application code's use of the code could not permit that optimization?

 

Is this a real problem?  If so, how to handle?  Compile the bootloader code without optimization?  Make sure I include application code in the compilation that exercises the bootloader functions I want to share?  Or, conclude it just isn't worth the hassle to try to share bootloader functions with application code that will be continually changing.

 

Thanks,

 

Dave Thomas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you don't want functions garbage collected still use gc-sections at the link but put the functions in a separate .c then DON'T pass ffunction-sections during the compile. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

then DON'T pass ffunction-sections during the compile. 

Compile all the files except the ones that have functions to be shared with application memory WITH ffunction-settings and leave that flag off for the file with the shared functions?

 

Is there a way to set compilation flags on a per file basis in AS6.1 Toolchain GUI?  Or should I just go with a separate makefile to get that done?

 

Thanks,

 

Dave Thomas 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Studio,  by default passes -ffunction-sections (and -fdata-sections) on the compilation of all C files. Let it continue to do that for all but the file that contains the uncalled functions. For that file make sure -ffunction-sections is not passed. 

 

In the Solution Explorer you can set special compilation options on individual files. The only thing I don't know is whether it's possible there to say "but not this option". All GCC -f options can be prefixed "no" so perhaps -fnofunction-sections *might* work. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tip!  I'll give it a try.

 

Dave THomas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's -noffunctions-sections instead of -fnofunctions-sections.

 

The build line now has both flags:

 

...  -Os -ffunction-sections -fdata-sections -g2 -Wall -mmcu=atmega328p -c -fno-tree-scev-cprop -fno-inline-small-functions -fsigned-char -std=gnu99 -MD -MP -MF "nordic_utils.d" -MT"nordic_utils.d" -MT"nordic_utils.o"  -noffunction-sections ...

Hopefully, whatever the last flag left to right wins, but I'll check it out.  That might even be a documented characteristic of the compiler (conflicting flags ok, right most flag wins).

 

Thanks again! 

Last Edited: Sat. Sep 20, 2014 - 02:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This has come up before.

Passing --undefined=foo to the linker will defeat garbage collection of foo's section.

I think that the attribute used is unnecessary.

Iluvatar is the better part of Valar.