This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
> > > All initialized globals seem to be put in the
> .bss
> > > with the exception of the globals initialized
> with
> > a
> > > constant (?).
> > > For instance int foo=0; ends up in .bss
> > > while
> > > int foo1=TICK_1; ends up in .data
> > > Again, the old gcc compiler sets all of them in
> > .data.
> > 
> >   Above, you said that "the initialisation is not
> > zero", but the example you
> > have here, you say that zero-inited variables end
> up
> > in .bss and non-zero-inited
> > variables end up in .data, and that is the correct
> > behaviour, by design.  If you
> > wish to change it, the
> -fno-zero-initialised-in-bss
> > flag that Alan mentioned
> > will move the zero initialised variables into the
> > .bss section for you.
> > 
> >     cheers, 
> >       DaveK
> > -- 
> > Can't think of a witty .sigline today....
> > 
> > 
> 
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]