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

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

[Fabrício de Novaes]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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.

Any answer or comment will be very appreciated.
Thank you in advance and best regards,


Fabrício de Novaes Kucinskis.

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

[Daniel Jacobowitz]

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

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

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

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

Yes, that would be useful.  There are other examples for LMA != VMA
where LMA is the correct load address.  For example:

1. LMA is an available memory area, VMA is "low memory", and a bit of
   initialization code moves the loaded code to low memory.  It can't
   be loaded directly there because there is currently running code
   already there, and loading on top of it will crash the system.

2. LMA is an unmapped address, VMA is a mapped address.  The loader
   doesn't know about mapping.  The init code turns on the mapping, at
   which point execution continues via VMA.

We do #2 in our embedded system.  

So this suggests that an option to load at LMA would be useful.  

   paul

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

[Daniel Jacobowitz]

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.
> 
> Any answer or comment will be very appreciated.

Replying to this old report again...

I was absolutely convinced for a long time that GDB's "load" wrote to
the VMA, a very confusing behavior.  I remember another bug being
reported that seemed to illustrate this also, but I can't find it.
However, today I actually tried it, and it did exactly the right thing:
wrote to the LMA!

Fabrício, if you still can reproduce this problem, could you send me
the output of "load" and tell me what version of GDB you were using?

-- 
Daniel Jacobowitz
CodeSourcery

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

[Daniel Jacobowitz]

On Fri, Sep 01, 2006 at 01:57:31PM -0300, Fabrício de Novaes Kucinskis wrote:
> Hello Daniel,
> 
> 
> I'm using GDB 5.2, an old version from mid-2002. I didn't know if the way
> this version loads addresses was right, or if it was a bug. You explained to
> me that GDB uses VMA by default, and you were probably right - for that
> version.

Aha - I might be mistaken, but it looks as if this was fixed about a
month after GDB 5.2 branched.  GDB has always requested the LMA, but in
mid-April a BFD bug was fixed in the setting of LMAs.

Thanks for responding.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Fabrício de Novaes]

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

Hello Daniel, what a quick answer! Thank you!

About your doubt:

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

Perhaps I didn't make myself clear.

I'm using a simulator so GDB can put the sections in any address, ROM or RAM.

My .boot section, for example, is loaded into the ROM area (starting at 0x00). I'd like to do the same with the .text section, but the VMA and LMA are different, and, as you just confirmed, GDB uses VMA.

I can't make VMA and LMA the same, or the program will not run in RAM. So the question is: there's a way to tell GDB to use LMA instead of VMA when loading a program?

Regards,


Fabrício.


Daniel Jacobowitz wrote ..
> 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

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

[Daniel Jacobowitz]

On Wed, Feb 22, 2006 at 03:30:20PM -0300, Fabrício de Novaes wrote:
> I can't make VMA and LMA the same, or the program will not run in
> RAM. So the question is: there's a way to tell GDB to use LMA instead
> of VMA when loading a program?

No, today there is not.  You might be able to accomplish this by using
objcopy to create a copy of the program with different VMAs, and
loading that.

-- 
Daniel Jacobowitz
CodeSourcery