Large lma delta using binutils 2.19

[James Blackburn]

On 03/03/2010 19:47, Daniel Jacobowitz wrote:
> On Wed, Mar 03, 2010 at 11:29:29AM +0000, James Blackburn wrote:
>> However the thing I'm still failing to see why the increment is the
>> last section's vma/lma delta.  Just like users have the expectation
>> that unspecified VMAs follow on from the previous, shouldn't the
>> same be true for the lma?
>
> If you change the relative delta, and your runtime copies from LMA to
> VMA at startup, then it's going to copy the following section to the
> wrong place.  The most likely scenario for this is with alignment.
> For instance, suppose there's normally 15 bytes of padding.

I'm a little confused. Before & after the patch, the vma hasn't changed. The patch simply moves the lma so that the sections are more tightly packed (as seems to be done currently with overlay sections). The code in ldlang.c should continue to correctly align the the lma to the section alignment.  In the manual there's an example on laying out ROM sections:
http://sourceware.org/binutils/docs-2.20/ld/Output-Section-LMA.html#Output-Section-LMA
If more sections were added, following on from .mdata, the gap in the physical address space would be the same as the vma gap, rather than packing the data in the ROM section as might be desired (and is done explicitly for the first data section in the example).

The runtime surely has to cope with any change in the lma, as happens when moving from a 2.17 linker to a new linker, right? It's very likely I'm missing something, could you flesh out how moving the lma might break expectations?

Cheers,
James