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



		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com