Re: [avr-chat] linker builds file too big, is it a bug?

[Erik Christiansen]

On Fri, Feb 11, 2011 at 03:55:19PM +0100, Massimiliano Cialdi wrote:
> Il giorno sab, 12/02/2011 alle 01.37 +1100, Erik Christiansen ha
> scritto:
> 
> > Does your linker script still have the usual line:
> > 
> >    .data    : AT (ADDR (.text) + SIZEOF (.text))
> > 
> > That sets the LMA for .data to follow on from .text, so ld really ought
> > to be checking that this also fits into the output section for .text
> > (i.e. text) just as you expect.

> Yes this line is present.

OK, I've had time to try the nicely potted test case, and the output of
"avr-objdump -h test.elf" shows that the LMA of .data that we'd expect.

However, in the output of "avr-objdump -D test.elf", VMAs are used for
display:

00007ca0 <_exit>:
    7ca0:   ff cf          rjmp  .-2         ; 0x7ca0 <_exit>
Disassembly of section .data:

00800060 <__data_start>:
  800060:   01 01          movw  r0, r2
  800062:   01 01          movw  r0, r2
  800064:   01 01          movw  r0, r2
  800066:   01 01          movw  r0, r2
  800068:   01 01          movw  r0, r2

So avr-objdump also doesn't explicitly show that the text memory region
will overflow. (I had hoped to see LMAs there, because that's what is
relevant when the file is loaded, and the numbers would exceed 32K, in
most satisfying fashion.)

In the map file, LMA awareness is explicit at the start of .data:

.data           0x00800060      0x5dc load address 0x00007ca2

but at:

                0x0080063c                _edata = .

there's no sign that ld is looking much past VMAs.

But the avr-specific VMA shouldn't affect LMA arithmetic, so that's no
excuse for not detecting memory region overflow, I do admit.

It's hard to believe that it has never checked for region overflow,
despite the consistency of the older versions of ld tried so far.

Erik