From: Virgil Anuichi <vanuichi@yahoo.com>
To: Dave Korn <dave.korn@artimi.com>, 'Alan Modra' <amodra@bigpond.net.au>
Cc: binutils@sources.redhat.com
Subject: RE: wrong initialized global variable (in the wrong section: .bss instead of .data)
Date: Thu, 10 Feb 2005 23:40:00 -0000 [thread overview]
Message-ID: <20050210190413.14574.qmail@web21005.mail.yahoo.com> (raw)
In-Reply-To: <NUTMEG0goZolmRBaYFk00000025@NUTMEG.CAM.ARTIMI.COM>
[-- 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
next prev parent reply other threads:[~2005-02-10 19:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-09 23:03 Virgil Anuichi
2005-02-10 4:25 ` Alan Modra
2005-02-10 17:26 ` Virgil Anuichi
2005-02-10 19:04 ` Dave Korn
2005-02-10 21:20 ` Dave Korn
2005-02-10 23:40 ` Virgil Anuichi [this message]
2005-02-11 0:05 ` Virgil Anuichi
2005-02-11 0:19 ` Virgil Anuichi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050210190413.14574.qmail@web21005.mail.yahoo.com \
--to=vanuichi@yahoo.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=dave.korn@artimi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).