From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29877 invoked by alias); 22 Feb 2006 18:23:05 -0000 Received: (qmail 29868 invoked by uid 22791); 22 Feb 2006 18:23:04 -0000 X-Spam-Check-By: sourceware.org Received: from satelite.dea.inpe.br (HELO satelite.dea.inpe.br) (150.163.30.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Feb 2006 18:23:03 +0000 Received: by satelite.dea.inpe.br (Postfix, from userid 550) id E6975128A48; Wed, 22 Feb 2006 15:30:20 -0300 (BRT) From: "Fabrício de Novaes" Subject: Re: Does GDB use VMA addresses when uploading an image to debug in a remote target? To: Daniel Jacobowitz Cc: gdb@sourceware.org Message-Id: <1140633020.8776@satelite.dea.inpe.br> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1140633020" Date: Wed, 22 Feb 2006 19:21:00 -0000 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00298.txt.bz2 This is a multi-part message in MIME format. --bound1140633020 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2778 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 RA= M. My .boot section, for example, is loaded into the ROM area (starting at 0x0= 0). 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 t= he question is: there's a way to tell GDB to use LMA instead of VMA when lo= ading a program? Regards, Fabr=EDcio. Daniel Jacobowitz wrote .. > On Wed, Feb 22, 2006 at 03:12:43PM -0300, Fabr=EDcio 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 --bound1140633020--