Re: Large lma delta using binutils 2.19

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Wed, Mar 03, 2010 at 08:03:21PM +0000, James Blackburn wrote:
> 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?

It's not uncommon to have something like this:

  __region_start = ADDR(.text)
  __region_end = ADDR(.data) + SIZEOF(.data)
  __region_load = LOADADDR(.text)

Then your startup code knows what to copy, and where to copy it from.
They don't have to be the same section.  But they all do have to have
the same VMA - LMA.

I don't claim mixing this with explicit VMA and implicit LMA is a
great idea... it isn't.

Going back to the example:

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

Now you'll have to define symbols for each new section.  If you don't,
they're not going to be copied to the right place by that startup code
sample.

Does that make more sense?

-- 
Daniel Jacobowitz
CodeSourcery