Date: Tue, 26 Sep 2000 13:51:41 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
cc: djgpp-workers AT delorie DOT com
Subject: Re: (fwd) startup-code
In-Reply-To: <200009260710.JAA04943@lws256.lu.erisoft.se>
Message-ID: <Pine.SUN.3.91.1000926134604.13268G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Tue, 26 Sep 2000, Martin Stromberg wrote:

> > However, Someone(tm) needs to make sure this works with DJGPP.
> > Profiling would be a good test case, I guess.
> 
> No. For mcount.c's "etext", I suggest we correct mcount.c. Otherwise a
> program that uses etext will not break until the poor coder tries to
> profile his code.

Sorry, I don't follow.

As far as I understand, PROVIDE is a means to make sure etext is 
available to C programs that declare it extern, but invisible to those 
who declare and define it (without extern).  Is that true?

If that's true, then using PROVIDE with the unmodified mcount.c should 
leave profiling intact, even if you remove the current definition of 
_etext from djgpp.djl.  Is that true?

If I'm still right, then the question whether or not we should change 
mcount.c is a separate one, to which we can return later.  For now, I 
simply suggested to use mcount.c as a test case to see if PROVIDE works 
in the DJGPP port of Binutils.