RE: A work-around Re: [avr-gcc-list] strange behaviour of avr-ld, maybe a bug?

[Boyapati, Anitha]

Hi Erik,

>Anitha, a quick test shows that this linker script addition provides
>cumulative overflow detection (using binutils 2.18.0):
>
>   . = ASSERT (_etext + SIZEOF (.data) <= 32K , "Error: .text + .data
>collectively overflow the text region." ) ;
>
>(Or use "ADDR (.text) + SIZEOF (.text)" in place of _etext, if that
>looks nicer.)
>
>The "32K" is the text region size in the test case we've used on
>avr-chat mail list. Ld syntax doesn't allow a variable in MEMORY region
>statements, unfortunately, so we currently seem stuck with a second
>magic number. At least, I haven't thought of a solution, here at 2
>a.m., beyond using 'INCLUDE <filename>' to bring in a line:
>
>   _text_size = 32K ;


Although I haven't tried, I think we can use something like LENGTH(.text)

http://sourceware.org/binutils/docs/ld/MEMORY.html#MEMORY


>
>and using the variable in the ASSERT. A line of awk could extract that
>from the linker script, but that might be over-finessing a work-around.
>
>I just inserted the ASSERT between .data and .bss output sections in the
>linker script.
>

Hmm..I just went through the problem over and again. Not much of a response in 
binutils ML either.

Say we need something like:

.data :
{

} (>text) || (>data)

It seems to be a general problem with any embedded system. I wonder how other 
targets are managing...


Anitha