Date: Tue, 26 Sep 2000 16:18:19 +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 <djgpp-workers AT delorie DOT com>
Subject: Re: (fwd) startup-code
In-Reply-To: <200009261235.OAA05095@lws256.lu.erisoft.se>
Message-ID: <Pine.SUN.3.91.1000926161513.13268U@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:

> > 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.
> 
> Yes, unless I (or somebody else) decides to try and profile a program
> containing "int etext".

This is a separate problem that existed all the time.  We could decide to 
change mcount.c to eliminate this problem, but that has nothing to do with 
testing whether PROVIDE works.  For the latter, leaving mcount.c 
unmodified, for as long as you test PROVIDE, is better.

> I'm seeing the problem from the perspective that we pollute the
> namespace, which means the problem isn't completely fixed until we
> don't do that anymore.

We don't have to solve everything in one go.  One step at a time is 
okay.