From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3512 invoked by alias); 1 May 2008 00:11:19 -0000 Received: (qmail 3502 invoked by uid 22791); 1 May 2008 00:11:18 -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; Thu, 01 May 2008 00:10:57 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 07B8B667A4; Thu, 1 May 2008 00:10:55 +0000 (UTC) From: Mike Frysinger To: Michael Snyder Subject: Re: the "load" command and the .bss section Date: Thu, 01 May 2008 00:11:00 -0000 User-Agent: KMail/1.9.7 Cc: gdb@sourceware.org References: <200804270509.34308.vapier@gentoo.org> <1209406914.4615.297.camel@localhost.localdomain> In-Reply-To: <1209406914.4615.297.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1801849.IJLVDKY4WG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804302010.59482.vapier@gentoo.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00000.txt.bz2 --nextPart1801849.IJLVDKY4WG Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 1893 On Monday 28 April 2008, Michael Snyder wrote: > On Sun, 2008-04-27 at 05:09 -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 ? > > > > once i adapted my habits to first load the ELF and then manually zero t= he > > bss, life was so much saner :). > > In my understanding, it is not GDB's responsibility to zero the > .bss section. That is the responsibility of the C Runtime. > > Otherwise, how could the program run without gdb in the picture? > > The gdb load command only addresses sections with the loadable > flag. .bss is not loadable. a fair point, but i think there is a valid use case for having an optional= =20 flag to tell gdb to do this. you may want to load a bare metal application= =20 that itself would have normally been loaded by another application (say you= r=20 typical bootloader), so the assumption is that certain aspects of the C=20 runtime have been initialized before the bare metal application is executed= .=20=20 Daniel also indicated that i wouldnt be the first (and probably not the las= t)=20 to experience this hiccup and ask for an optional (streamlined) method for= =20 accounting for this. -mike --nextPart1801849.IJLVDKY4WG 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) iQIVAwUASBkKk0FjO5/oN/WBAQIDgQ//VYtWwktHFV7/f6SdgCuLYkADYr0/Ql7D dApy00QXfgHTd9Tm8nSxUyJ2hlLWpBYMT/xzcOiDYHwN5IRp6o06KziS0lFc+uGW y51stqNP/ivH5Q+QSwsqLlkfAjfy10zI/jDODt4efQb1qBWxnnObkXRUk4Lgeowa Fvs6g7X5rJRs5xc6NoxCbKql8iUxZ6mA328L2KZFOIevoGBzLiIvatRMdzEezWIx SJ77N+UZ/vrtqtpDUifopXDBfPWExOneHf0drqAz0Ru/pA0G0uwLQdjTvMiKY7Rr uDs28nuohCq/1eVy7kPLEu5subJa88I4K6Hp2D0/A/P00TbWNtNaNuTnA68fKalA FxMLTwgwq1Cd+mTdebq7EOEiTLEmsT8jbR2MN68v899kJFQfVysA6J7y1yi0OhQD p9g4J2N0zPsQileGMBu/nrAz1cCmis1nj9uv9xSYMOibCUraFTFfPNvB3NQSuHTJ OAnzFxW/cQKFgegCuajX1UooOcRuW7q92FTcBQX4MNR+eKjGVVFVaKaXsMKT0eSd 1LqHQoCcYGFYUfKnt5c/mEdHA7QRYMYHAJ7DBlN4YotTWqyfPCvoAwuUxIHra2LX O876pM5XLIFwuZlz116lVtYLwL6/Lk5frBAvGQ9yDehJLWvc6COrw58nt/6+lzs8 oAQ5xIp2MOA= =Kh32 -----END PGP SIGNATURE----- --nextPart1801849.IJLVDKY4WG--