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

[Erik Christiansen]

On Mon, Feb 21, 2011 at 02:28:47AM +0800, Boyapati, Anitha wrote:
> > Erik wrote:
> >
> >   . = ASSERT (_etext + SIZEOF (.data) <= 32K , "Error: .text + .data
> >collectively overflow the text region." ) ;

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

Yes that will work, minus one '.', because it is the text memory region,
not the .text output section to which we refer here. (The linker scripts
might perhaps be easier for everyone to follow if we used more
real-world memory region (or segment) names?) e.g.:

MEMORY
{
  flash   (rx)  : ORIGIN = 0, LENGTH = 32K
  ram    (rw!x) : ORIGIN = 0x800060, LENGTH = 2K
  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 1K
}

Let me just confirm LENGTH works for us ... Yep the line:

. = ASSERT (_etext + SIZEOF (.data) <= LENGTH(flash) , "Error: .text + .data
collectively overflow the flash memory." ) ;

still detects overflow, and generates:

/usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: Error: .text + .data
collectively overflow the flash memory.

essentially as before.

<$.02>
I understand that it may seem less disturbing to remain with the
traditional "text" region name, but the more explicit the linker script,
the less it will put off embedded programmers who are dipping their toes
in scripts for the first time, I think. </$.02>

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

No there isn't; I had hoped for more response to my query, but I am
pleased to see the good response your work there is receiving.

Though absent these last few years, I'd previously spent quite a few
years lurking on binutils, and the traffic on other than 32 bit targets
was mostly negligible, IIRC.

> 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...

Well, my experience with PowerPC and v850 targets, as well as reading
assorted other linker scripts, is that it's done conventionally, i.e.
explicitly setting the LMA to the next address in the text region, while
the VMA goes into the data region:

  .data    : AT (ADDR (.text) + SIZEOF (.text))
  {
   ...
  } > data

Oh, if you meant the overflow detection in this case, then I suspect it
probably still works for 32 bit, so the big boys are happy. 

Anyway, explicit overflow detection in the linker script is a more
flexible solution. At least we can optimise at will, without having to
try to push a patch upstream. And I for one, will be adopting your
improvement on this fix. :-)

Erik

-- 
In all affairs it's a healthy thing now and then to hang a question
mark on the things you have long taken for granted.
                                                    -- Bertrand Russell