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

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

[Virgil Anuichi]

Hello,

I have an issue with the place the global variables
are linked into.
I have an older script:
ENTRY(__start)
SECTIONS
{
    . = 0x81200000;
  .text :
    {
     _ftext = . ;
    *(.init)
     eprol  =  .;
    *(.text)
    *(.fini)
    *(.rodata)
    *(.rodata.*)
     _etext  =  .;
   }

  .data :
   {
   _gp = ALIGN(16) + 0x8000;
   _fdata = . ;
    *(.data)
    CONSTRUCTORS
    *(.sdata)
   }
   _edata  =  .;
   _fbss = .;
  .sbss : {
    *(.sbss)
    *(.scommon)
  }
  .bss : {
    *(.bss)
    *(COMMON)
  }
   _end = .;
}

Now I'm compiling with gnu3.4.1 (I've already updated
the .rodata section to .rodata.*. I have a feeling I'm
still missing some other changes.
Right now all my initialized global variables end up
in the .bss section, which is wrong.
Could somebody help?
And, maybe, send me a link to the right docs? (new
sections, etc.)

Thanks,
Virgil


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

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

[Alan Modra]

On Wed, Feb 09, 2005 at 12:26:53PM -0800, Virgil Anuichi wrote:
> Right now all my initialized global variables end up
> in the .bss section, which is wrong.

Is the initialization zero?  gcc -fno-zero-initialized-in-bss

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Virgil Anuichi]

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

Thanks,
Virgil

--- Alan Modra <amodra@bigpond.net.au> wrote:

> On Wed, Feb 09, 2005 at 12:26:53PM -0800, Virgil
> Anuichi wrote:
> > Right now all my initialized global variables end
> up
> > in the .bss section, which is wrong.
> 
> Is the initialization zero?  gcc
> -fno-zero-initialized-in-bss
> 
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 



		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

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

[Dave Korn]

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

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

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Dave Korn

> will move the zero initialised variables into the .bss section 
                                                    ^^^^
  I meant .data, of course!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

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

[Virgil Anuichi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4833 bytes --]

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 

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

[Virgil Anuichi]

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 
 

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

[Virgil Anuichi]

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