use LMA instead of VMA?

use LMA instead of VMA?

[Torsten Mohr]

Hi,

i'd like to test my startup code in crt0.S but have some
problems with that as gdb uses the sections VMA instead
of the LMA.

For this i can't test my code in the simulator, as .data
and so on are always overwritten with incorrect data.

At the moment i use the preprocessor and -DREAL_TARGET=0 or =1
to generate an ELF file for the target or for the simulator.

Is there a better way to work around gdbs behaviour here?

Would it work to use objcopy --change-section-vma .data= \
load_address(.data) to set a sections vma?

Or would that crash something else then?

What else would be the preferred way to test a startup code?


Best regards,
Torsten.

Re: use LMA instead of VMA?

[DJ Delorie]

> i'd like to test my startup code in crt0.S but have some problems
> with that as gdb uses the sections VMA instead of the LMA.

Why would this confuse gdb?  If the crt0 code is *running* it should
already be at its VMA.  In the cases where LMA and VMA differ in my
projects, it's because I need to initialize RAM from ROM, so I don't
need gdb to know about the data until after I've moved it to its VMA.

Maybe you need to tell us more about how your code is set up?

Re: use LMA instead of VMA?

[Torsten Mohr]

Hi,

> > i'd like to test my startup code in crt0.S but have some problems
> > with that as gdb uses the sections VMA instead of the LMA.
>
> Why would this confuse gdb?  If the crt0 code is *running* it should
> already be at its VMA.  In the cases where LMA and VMA differ in my
> projects, it's because I need to initialize RAM from ROM, so I don't
> need gdb to know about the data until after I've moved it to its VMA.
>
> Maybe you need to tell us more about how your code is set up?

ok, maybe this needs some more explanation.  In a project i
use my own startup code and in this one i do several things:

- set up stack and registers
- clear .bss
- copy .data from ROM to RAM

To place the content of .data to ROM i use the following
in my linker script:

  .data :
  {
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
    CONSTRUCTORS
  } > ram AT > rom

When i look at the section .data, "v850e-unknown-elf-objdump -h"
tells me (only .data):

Idx Name          Size      VMA       LMA       File off  Algn
  7 .data         00000828  03ff7000  0000730c  00009000  2**2
                  CONTENTS, ALLOC, LOAD, DATA

When i generate an SREC file that i burn into the flash micro
everything is placed where i expect it, the content of .data
is placed at LMA.

So my startup code needs to copy it from LMA to VMA, where the
rest of the code expects it.

But when i try to simulate it in GDB, GDB loads the content of
.data to VMA and i _must_ _not_ copy anything from LMA to VMA,
because at LMA there is just nothing.  The correct data are
already at VMA.

To my understanding every code that places something into .data
needs to behave like that.  That's why i think there could/should
be a standard solution.


At the moment i use -DREAL_TARGET=0 or =1 per command line to the
compiler and assembler and behave differently in the startup code
and very small parts of the rest of the code (I/O over serial line).
This works quite fine.  My  project behaves ok in the simulator now,
but not in the real target.

So i'd like to also test my startup code now, but at the moment i
don't see a way for that.

But maybe i miss something, if anybody had a solution for that that
would be great.


Best regards,
Torsten.
 

Re: use LMA instead of VMA?

[DJ Delorie]

Are you using the "AT>REGION" syntax to embed the .data section into,
say, the .text section?  I use the same logic you use for the m32c,
and it has no problem running in the simulator that way.  Check out
the m32c linker scripts (in newlib's src/libgloss/m32c) to see how
it's done.

Re: use LMA instead of VMA?

[Daniel Jacobowitz]

On Sat, Jun 10, 2006 at 05:04:22PM -0400, DJ Delorie wrote:
> 
> > i'd like to test my startup code in crt0.S but have some problems
> > with that as gdb uses the sections VMA instead of the LMA.
> 
> Why would this confuse gdb?  If the crt0 code is *running* it should
> already be at its VMA.  In the cases where LMA and VMA differ in my
> projects, it's because I need to initialize RAM from ROM, so I don't
> need gdb to know about the data until after I've moved it to its VMA.

This seems to be a pretty standard problem - if you have any kind of
loader, then your crt0 is expected to run at VMA, but if you don't have
a loader, crt0 has to run at LMA and handles the switch to VMAs.  I've
used a couple different sets of tools now that behaved this way, most
recently ARM's.

-- 
Daniel Jacobowitz
CodeSourcery