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

["Dave Korn" <dave.korn@artimi.com>]

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