Date: Tue, 30 Oct 2001 15:02:58 -0500
Message-Id: <200110302002.f9UK2w421501@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <9743-Tue30Oct2001115500+0200-eliz@is.elta.co.il>
Subject: Re: Patch for develop.txi: BSS and restarted programs
References: <3BDDD2F5 DOT 4D609543 AT phekda DOT freeserve DOT co DOT uk> <9743-Tue30Oct2001115500+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> That @dfn is not really approppriate here, since you are not
> explaining what BSS is.  Better use @code{bss}, or even "the
> @code{bss} section".

If you're going to use @code, you should use ".bss" instead of "bss".
If you use dfn, use BSS instead of bss.  Use BSS (undecorated - it's
just an acronym) when referring generically to the uninitialized data,
and @code{.bss} when specifically talking about the COFF section by
that name.  Yeah, sometimes it will be hard to decide, but they're
fairly interchangeable.

> The _real_ problem is not with the startup code.  The variables in the
> BSS section are AFAIK initialized by the linker, not by the startup
> code.

No, the stub zeros out bss at run-time.  If you're running an unexec'd
image, the unexec should change the .bss memory range to .data so that
it acts like initialized data.