I'm using the gcc toolset built into a silicon vendor's software along with a boot loader that can skip any 8K blocks of code whose hash matches what's already in the device, and would like to arrange things to minimize upload time after test builds. Since most changes happen to a small number of compilation units which comprise a small minority of the code image, and the compilation units that change infrequently don't use any symbols which are in the frequently-changing parts, I would expect that one could reduce the number of circumstances requiring changes to the parts of the code image associated with rarely-changing parts of the code by laying out memory as (SU = stable units; OCU = often-changing units)
Flash:
[bot] | startup | SU code | OCU code | [unused] | OCU const | OCU init | SU init | SU const | [top]
RAM:
[bot] | [stack] | SU bss | OCU bss | [unused] | OCU data | SU data | [top]
If each of the SU flash sections only contains references to other things within SU flash or RAM sections, then changes to the OCU portions of the code would not affect the addresses of anything referenced within an SU flash section, and would thus not require any changes to 8K blobs that contain only SU code, SU const, or initial values for SU data.
What would one have to do in a linker script to designate some compilation units as "SU" for purposes of the above layout, and have it organize memory as shown above? Note that stack is being placed at the bottom of RAM to ensure that stack overflow will cause a trap rather than resulting in arbitrary memory corruption, but my main focus is on how to make the addresses of SU parts of the program be independent of the contents of anything else.
If gcc can't handle such top-down placements as indicated here, what would one have to partition storage so that all of the SU parts would start at fixed addresses and accommodate the resulting discontinuity in the flash storage of initial values for the data section?