From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3854 invoked by alias); 1 May 2008 02:03:21 -0000 Received: (qmail 3842 invoked by uid 22791); 1 May 2008 02:03:20 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 02:03:02 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 337E23C1E2 for ; Wed, 30 Apr 2008 19:03:01 -0700 (PDT) Subject: Re: the "load" command and the .bss section From: Michael Snyder To: gdb@sourceware.org In-Reply-To: <200804302010.59482.vapier@gentoo.org> References: <200804270509.34308.vapier@gentoo.org> <1209406914.4615.297.camel@localhost.localdomain> <200804302010.59482.vapier@gentoo.org> Content-Type: text/plain Date: Thu, 01 May 2008 02:03:00 -0000 Message-Id: <1209607380.4615.388.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00001.txt.bz2 On Wed, 2008-04-30 at 20:10 -0400, Mike Frysinger wrote: > 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 the > > > 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 > flag to tell gdb to do this. you may want to load a bare metal application > that itself would have normally been loaded by another application (say your > typical bootloader), so the assumption is that certain aspects of the C > runtime have been initialized before the bare metal application is executed. > Daniel also indicated that i wouldnt be the first (and probably not the last) > to experience this hiccup and ask for an optional (streamlined) method for > accounting for this. That's why there are different implementations of "load". A bare-metal target would presumably wind up using the appropriate "load" version. However, I do not disagree. In fact, I agree -- having an option to "load" that would tell it to clear certain sections (such as .bss) automatically would be a handy thing.