RE: wrong initialized global variable (in the wrong section: .bss instead of .data)

[Virgil Anuichi <vanuichi at yahoo dot com>]

Unfortunatelly, there's no such option for this
particular compiler. 
I'll have to ask back those guys at Broadcom.

Virgil

--- Virgil Anuichi <vanuichi@yahoo.com> wrote:

> Hi guys, 
> 
> Sorry to bother you again. There were 2 pieces of
> the
> puzzle here. And that's why I've got confused.
> 1. The new compiler indeed changed. 
> 2. Our loader doesn't initialize the .bss section to
> 0. (I figure that out the hard way).
> All this mishmash makes sense now and I'll try the
> option you mentioned.
> 
> Thanks a lot,
> Virgil
> 
> --- Virgil Anuichi <vanuichi@yahoo.com> wrote:
> 
> > Hi guys,
> > 
> > I guess I'm confused now.
> > 1-All these particular variables are initialized.
> To
> > 0. (Whether through a previously defined constant
> or
> > not.)
> > 2-The only flags I use to compile with is
> > -march=sb1,
> > since I run on a broadcom MIPS processor. 
> > 3-The old compiler (mips64-sb1sim-gcc) puts all
> > these
> > variables in the .data section, the new one
> > (gcc3.4.1
> > or, for me, sb1-elf-gcc) puts some in .bss some in
> > .data even though both are initialized to 0.
> (again,
> > through a previously defined constant ot not).
> > 4-I'm again confused by the following paragraphs I
> > took from 
> >
>
http://www.caldera.com/developers/gabi/2003-12-17/ch4.sheader.html:
> > 
> > .bss
> > This section holds uninitialized data that
> > contribute
> > to the program's memory image. By definition, the
> > system initializes the data with zeros when the
> > program begins to run. The section occupies no
> file
> > space, as indicated by the section type,
> SHT_NOBITS.
> > 
> > 
> > .data and .data1
> > These sections hold initialized data that
> contribute
> > to the program's memory image. 
> > 
> > And again, I understand a global like 
> > int foo; should end up in .bss. And it does.
> > 
> > My problem is that all global variables are ending
> > up
> > there. Including the ones initialized. 
> > 
> > To add to the puzzle I've added downwards a copy
> > from
> > the objdump file:
> > 
> > Disassembly of section .data: 
> > 
> > First compiled with the old compiler:
> > 
> > 00000000 <lgen_ticks>:
> >    0:   000009c4        0x9c4
> > 
> > 00000004 <countdown1>:
> >    4:   000009c4        0x9c4
> > Disassembly of section .bss:
> > 
> > 00000000 <disableKeepAlive_g>:
> >    0:   00000000        nop
> > 
> > 00000004 <keepAliveTick_g>:
> >    4:   00000000        nop
> > 
> > 00000008 <ka_worst_ticks>:
> >    8:   00000000        nop
> > 
> > 0000000c <ka_last>:
> >    c:   00000000        nop
> > 
> > 00000010 <ka_worst>:
> >   10:   00000000        nop
> > 
> > 00000014 <ka_index>:
> >   14:   00000000        nop
> > 
> > 00000018 <cpu_totals>:
> >         ...
> > 
> > 00000020 <cpu_busy>:
> >         ...
> > 
> > 00000028 <cpu_idles>:
> > 
> > Second (the following) using the new compiler:
> > 
> > Disassembly of section .data:
> > 
> > 00000000 <lgen_ticks>:
> >    0:   000009c4        0x9c4
> > 
> > 00000004 <countdown1>:
> >    4:   000009c4        0x9c4
> > Disassembly of section .bss:
> > 
> > 00000000 <disableKeepAlive_g>:
> >    0:   00000000        nop
> > 
> > 00000004 <keepAliveTick_g>:
> >    4:   00000000        nop
> > 
> > 00000008 <ka_worst_ticks>:
> >    8:   00000000        nop
> > 
> > 0000000c <ka_last>:
> >    c:   00000000        nop
> > 
> > 00000010 <ka_worst>:
> >   10:   00000000        nop
> > 
> > 00000014 <ka_index>:
> >   14:   00000000        nop
> > 
> > 00000018 <cpu_totals>:
> >         ...
> > 
> > 00000020 <cpu_busy>:
> >         ...
> > 
> > 00000028 <cpu_idles>:
> >   28:   00000000        nop
> > 
> > 0000002c <ticksFor1s_g>:
> >   2c:   00000000        nop
> > 
> > None of the globals changed in the way they are
> > defined. However, most of them "moved" from .data
> to
> > .bss. All are initialized. The ones left in .data
> > section are still there because, it seems, they
> were
> > initialized using a constant instead of a straight
> > forward number.
> > 
> > Again, maybe I'm still wrong and don't get your
> > point
> > of view, but, since both compilers use the same
> flag
> > (-march=sb1, nothing else) how come the globals
> are
> > seen suddenly in a new light (section)?
> > 
> > Thanks,
> > Virgil
> > 
> > 
> > --- Dave Korn <dave.korn@artimi.com> wrote:
> > 
> > > > -----Original Message-----
> > > > From: binutils-owner On Behalf Of Virgil
> Anuichi
> > > > Sent: 10 February 2005 14:07
> > > 
> > > > The initialization is not zero. And that's the
> > > > problem. In fact, a global looking like int
> > foo=0;
> > > > would come up with an undidefined value, in
> the
> > > .bss.
> > > 
> > >   The .bss section is cleared to zero by the
> > runtime
> > > startup code, so I suspect
> > > your problem is to do with that.  Are you using
> > > -nostdlib or -nodefaultlibs (or
> > > even -nostartfiles)?  Both those flags exclude
> the
> > C
> > > runtime startup files from
> > > the link.
> > > 
> > > > I actually dig some more and it's not the
> linker
> > > > script, rather the compiler. The objdump shows
> > me
> > > even
> > > > the .o file has the global in the .bss
> section.
> > > The
> > > > old compiler works fine: it puts it in .data
> > > section.
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com