Re: the "load" command and the .bss section

[Mike Frysinger <vapier@gentoo.org>]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]