This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: wrong initialized global variable (in the wrong section: .bss instead of .data)
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Virgil Anuichi'" <vanuichi at yahoo dot com>,"'Alan Modra'" <amodra at bigpond dot net dot au>
- Cc: <binutils at sources dot redhat dot com>
- Date: Thu, 10 Feb 2005 15:58:34 -0000
- Subject: RE: wrong initialized global variable (in the wrong section: .bss instead of .data)
> -----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....