Re: Using Named Address spaces.

"Thomas, George" <[email protected]>
Newsgroups gmane.comp.hardware.avr.gcc
Message-ID <1B24C0912E35814DAAAC596A7FFAB32048D125CC@penmbx01>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.