the "load" command and the .bss section

the "load" command and the .bss section

[Mike Frysinger]

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

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

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

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

[Daniel Jacobowitz]

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

IIRC we have a couple of old requests for a version of load which
drops things at their VMA.  That one would have to clear the BSS.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Mike Frysinger]

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

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...
>
> IIRC we have a couple of old requests for a version of load which
> drops things at their VMA.  That one would have to clear the BSS.

what would be the way to extend things ?  getopt-style flags to load ?  a new 
command ?  i may take a look (according to my wants/needs), but i'm not 
terribly good with gdb code base, so i wont promise anything ...
-mike

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

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

[Daniel Jacobowitz]

On Sun, Apr 27, 2008 at 05:45:58PM -0400, Mike Frysinger wrote:
> what would be the way to extend things ?  getopt-style flags to load ?  a new 
> command ?  i may take a look (according to my wants/needs), but i'm not 
> terribly good with gdb code base, so i wont promise anything ...

Beats me.  Either one, I suppose, and maybe a matching MI
-target-download option.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Michael Snyder]

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.

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

[Mike Frysinger]

[-- 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 --]

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

[Michael Snyder]

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.

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

[Daniel Jacobowitz]

On Wed, Apr 30, 2008 at 07:03:00PM -0700, Michael Snyder wrote:
> That's why there are different implementations of "load".
> A bare-metal target would presumably wind up using the 
> appropriate "load" version.

Well that's probably why historically there _were_ different
implementations of load.  But I doubt it is still justified.

Only the three m32r targets, the remote-mips target (for specific
monitors), remote-sim, and target remote have implementations of load.
It looks to me like target remote's would work for all of them except
the sim.  m32r is just using a wrapper around generic_load already.
monitor and mips are using srec but could do that anyway for large
writes.  Presumably, at least.  But I have no way to test any of them
so I leave them alone.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Michael Snyder]

On Wed, 2008-04-30 at 23:32 -0400, Daniel Jacobowitz wrote:
> On Wed, Apr 30, 2008 at 07:03:00PM -0700, Michael Snyder wrote:
> > That's why there are different implementations of "load".
> > A bare-metal target would presumably wind up using the 
> > appropriate "load" version.
> 
> Well that's probably why historically there _were_ different
> implementations of load.  But I doubt it is still justified.
> 
> Only the three m32r targets, the remote-mips target (for specific
> monitors), remote-sim, and target remote have implementations of load.
> It looks to me like target remote's would work for all of them except
> the sim.  m32r is just using a wrapper around generic_load already.
> monitor and mips are using srec but could do that anyway for large
> writes.  Presumably, at least.  But I have no way to test any of them
> so I leave them alone.

Right.  I think there used to be more implementations, but 
some have probably slipped quietly into the night, along with
their discontinued targets and architectures.

Remote and sim are probably among the main ones that still
need to be supported.  

Reviewing the thread -- the OP says he is bringing up a new
board using jtag.  I'm not clear which version of load that
implies -- remote?

So, given that there are only a few versions to support, 
instead of the plethora I was recalling (eg. we probably 
don't need to worry too much about a.out...), maybe there
is a choice to make here, between:

  a) Making up a spec for the "load" command and then
  making sure that the remote, sim, and ??? versions all
  conform to that spec, or

  b) Just adding features such as "clear the .bss section"
  to the version of load that we expect to use the most
  (remote?), and leaving the other(s) alone.

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

[Daniel Jacobowitz]

On Thu, May 01, 2008 at 12:23:57PM -0700, Michael Snyder wrote:
>   b) Just adding features such as "clear the .bss section"
>   to the version of load that we expect to use the most
>   (remote?), and leaving the other(s) alone.

Right.  I think generic_load (used by remote and m32r) covers 99% of
uses that would care about this.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Michael Snyder]

On Thu, 2008-05-01 at 15:32 -0400, Daniel Jacobowitz wrote:
> On Thu, May 01, 2008 at 12:23:57PM -0700, Michael Snyder wrote:
> >   b) Just adding features such as "clear the .bss section"
> >   to the version of load that we expect to use the most
> >   (remote?), and leaving the other(s) alone.
> 
> Right.  I think generic_load (used by remote and m32r) covers 99% of
> uses that would care about this.

OK by me.