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

[Erik Christiansen]

> >
> >If you compile you will obtain a binary bigger than 32KB
> >I would expect a linker error like:
> >region `text' overflowed by xx bytes
> >
> 
> I don't think so. If .text section alone is more than 32KB, linker
> will complain. I don't think that is the case here.

Ahem, avr-ld is doing what you describe, but that is the problem. Where
more than one output section's LMA directs its LOAD data to a common
memory region, the test you describe is entirely inadequate. That is why
gnu ld _has_ historically detected memory region overflow. Although I
only found one unrelated match on "overflow", using the search engine at
the binutils ML archive (http://sourceware.org/ml/binutils/), my own
archive from 2006 has this:

>>>
Message-ID: <address@hidden>

 > We have a large program in which many different object
 > file sections are placed into various fixed size
 > memory regions and I want to be sure that the linker
 > will tell me when I overflow one of these regions.

I think that you can be sure of this.

Cheers
   Nick
<<<

Nick Clifton's response can be taken as definitive, I'd suggest.

Being curious whether the regression is generic or specific to the avr
toolchain, I've queried binutils. In a day or two we should have a
clearer idea on that score. (Feedback thus far is inconclusive.)

When we invoke LMA concatenation across output sections, as is done for
.data in the avr default linker scripts, ld is performing the related
arithmetic, and it is a bug for it to fail to test for overflow as it
(currently blindly) stuffs bytes into the destination memory region.

On closer examination, I think you'll probably agree. ;-))

Erik

-- 
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite."
                           - Bertrand Russell, _Sceptical_Essays_, 1928