From: Erik Christiansen Sent: Monday, March 18, 2013 2:58 PM > George, your question on back-filling flash[1-4] with arbitrary .text is > possibly more completely answered if we also look at some limitations > faced by ld. > > Firstly, ld does not know that flash[1-4] are unoccupied, while it is > linking input sections according to the active script. Data and code > arrive willy-nilly, in whatever link order the user throws at ld. Until > linking is complete, any of flash[1-4] might at any time be populated by > a late xxx.o file. What information could ld use to decide to clobber > flash[1-4] with arbitrary .hightext? > > Please note that the linker script _does_ populate any unutilised flashN > pages _above_ the last populated flashN page. It is only the deliberate > gap use-case which reserves memory. > > Secondly, even if we did implement some way to promise to ld that > flash[1-4] would not be used for flashN, there remains the problem that > ld cannot flow code around memory holes. That feature has been requested > before, as in: > > http://sourceware.org/ml/binutils/2012-01/msg00183.html > > The reply to that post effectively rules out a backwards memory use > interpretation in our holey use case. > > That only leaves memory reservation as a real-world purpose for > populating a high flashN, with lower flashN vacant, AFAICT. >
I understand the issues in the implementation but I was just curious. Thanks for the detailed response. In such a situation, result from avr-size should have to be taken with a pinch of salt. As avr-size is not aware of the paged structure of flash. Should this information be made available to avr-size ? IMO If its available, the user may be able to understand how much space is available for code if an information like sizeofcontinuousblock is provided by avr-size. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
