From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20668 invoked by alias); 27 Apr 2008 21:46:08 -0000 Received: (qmail 20658 invoked by uid 22791); 27 Apr 2008 21:46:07 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Apr 2008 21:45:41 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8C8B9671B3; Sun, 27 Apr 2008 21:45:38 +0000 (UTC) From: Mike Frysinger To: Daniel Jacobowitz Subject: Re: the "load" command and the .bss section Date: Mon, 28 Apr 2008 08:34:00 -0000 User-Agent: KMail/1.9.7 Cc: gdb-patches@sourceware.org References: <200804270509.34308.vapier@gentoo.org> <20080427135600.GA9356@caradoc.them.org> In-Reply-To: <20080427135600.GA9356@caradoc.them.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_BQPFI1zjUfVXKKp" Message-Id: <200804271745.37849.vapier@gentoo.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00628.txt.bz2 --Boundary-00=_BQPFI1zjUfVXKKp Content-Type: multipart/signed; boundary="nextPart1243414.Qy7t44u53y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1243414.Qy7t44u53y Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 1419 On Sunday 27 April 2008, Daniel Jacobowitz wrote: > On Sun, Apr 27, 2008 at 05:09:31AM -0400, Mike Frysinger wrote: > > i was doing a new board port using jtag and so was leveraging the "load" > > command to setup the initial ELF in the relevant memory regions. things > > kept crashing on me and then i realized that the loading process wasnt > > actually zeroing out the bss. is there a reason for this ? i googled > > and flipped through the manual, but the details on what exactly the > > "load" command is supposed to do is a bit on sketchy side. from what i > > can tell from the gdb source code and the actual output from running the > > command, it walks the section headers (rather than the program headers = ?) > > and loads up everything that is in the file. since the bss section > > doesnt actually exist in the file and is only allocated, that is why it > > gets skipped ? > > Load puts things at their LMA rather than their VMA. So it assumes > that whatever sets up load -> virtual also handles bss; it's more like > flash programming than like the Linux kernel's loader. Heck, > sometimes it is flash programming... ah, now that i know the intentions, may i suggest the following to the=20 documentation. -mike 2008-04-27 Mike Frysinger * gdb.texinfo (Commands for Managing Targets): Clarify load command wrt load/virtual addresses and handling of allocated sections. --nextPart1243414.Qy7t44u53y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 827 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iQIVAwUASBT0AUFjO5/oN/WBAQIk8g//Xesj39fx5wwNlf5DCA5Ds2OEa3fSwNqp 7llf79+UVBmqeUKCx8nHr20S5LixUSbmvYq9LrGc9/6LfM8YZfh0m49WJnbjydXH l5lc117uyaRq4Nf3UWKVadepsSx4cKmv5hPQ9xKQcrNAsF1MnWWCALYUG3Fa9MV3 rhGyPAXPz1D3I9iGszWKGFvZfKG5Hrfo4o6K+FfscQ4MDa2gNk/Vm0Kg9+NcNavg mPxO85TZCFMkuIRr3ac9eIJqB3kC3+8kAtwHX96KgnDLBhw97iibbWGnArypk8IF sUigcAln1wkDTuwSrf+pVwY8ZD7S6WzGcJ6ZPrJ1DwiNP4IwibItYN0zSf6bXt0q FVLsap4cZka1vHq2HuKLm6qKraI3Ch9U90uuYdUb3M9Lak2vQhjNaBlspK9H9XDw Wi/413nv2YS7YyvxNT1x3EJbwTl7YunK8gCk47ZrsQZIqIlcrwNSPTmi+CTe4VQL LKUCGC843q+CHUcXU4fBCaaIWJt2TQfRW8QT5N0VrXbuA5rpZZ4+rQIV8/15IH4s NO5A9ZvqwkGCLNX2uepyJtVp/bq6QlLtiXkRtu+/KA3wpJCmn5e1HKxg+huY+oNB 62acFjspnStPO3pmUkdkRno/XAD3hw4LdJpfnwsEFemVGMG1RQ8lY3cFIPD7DqY3 8gKJjMy+uNU= =wlNK -----END PGP SIGNATURE----- --nextPart1243414.Qy7t44u53y-- --Boundary-00=_BQPFI1zjUfVXKKp Content-Type: text/x-diff; charset="iso-8859-1"; name="gdb-clarify-load.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb-clarify-load.patch" Content-length: 1278 Index: gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.487 diff -u -p -r1.487 gdb.texinfo --- gdb.texinfo 24 Apr 2008 12:09:49 -0000 1.487 +++ gdb.texinfo 27 Apr 2008 21:43:57 -0000 @@ -12795,10 +12795,12 @@ If your @value{GDBN} does not have a @co execute it gets the error message ``@code{You can't do that when your target is @dots{}}'' -The file is loaded at whatever address is specified in the executable. -For some object file formats, you can specify the load address when you -link the program; for other formats, like a.out, the object file format -specifies a fixed address. +The file is loaded according to the load addresses (rather than virtual) as +is specified in the executable. It is expected that the target system will +do the actual relocation, and in the process, handle such things as setup of +allocated sections (e.g. the bss). For some object file formats, you can +specify the load address when you link the program; for other formats, like +a.out, the object file format specifies a fixed address. @c FIXME! This would be a good place for an xref to the GNU linker doc. Depending on the remote side capabilities, @value{GDBN} may be able to --Boundary-00=_BQPFI1zjUfVXKKp--