the "load" command and the .bss section

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

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

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

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

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.

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

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.

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

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.

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