Re: Does GDB use VMA addresses when uploading an image to debug in a remote target?

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 22, 2006 at 03:12:43PM -0300, Fabrício de Novaes wrote:
> Hi all,
> 
> 
> I have a GCC application that will run in a board with an ERC32
> (SPARC) processor. For many reasons, this app has to run in RAM, not
> ROM.
> 
> So, the ELF32 image has a ".boot" section which starts the board and
> copies the main program from a ".text" section to RAM. This .text
> section has different LMA (pointing to ROM) and VMA (RAM) addresses,
> as you can see below:
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .boot         00001320  00000000  00000000  000000b4  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .text         0001d1b0  02001000  00001320  000013d8  2**3
>                   CONTENTS, ALLOC, LOAD, CODE
> [...]
> 
> 
> I'm trying to debug this app using GDB and a simulator. My problem is
> that, when I load the image to debug, the .text section is already in
> the 0x2001000 address (VMA), and the LMA area (starting from 0x1320)
> is empty - so I can't debug appropriately the routine that copies the
> .text section to RAM.
> 
> I'd like to know if GDB loads sections from an ELF file to a target
> using the VMA addresses and, if yes, if it's possible to change this
> behavior and tell it to send my .text section to its LMA address.

GDB does use the VMA, as you've surmised.

I'm not sure that what you're suggesting makes sense.  How could
GDB send the text section to its LMA, if that's a ROM address?
The stub will be unable to write to ROM, unless (for example)
it is transparently rewriting a flash device or shadowing it with
RAM.

I recently encountered this problem in another context, where the stub
did support reflashing; so maybe GDB needs to be more flexible about
it.  I'm not sure.

-- 
Daniel Jacobowitz
CodeSourcery