From:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id:	<200009261235.OAA05095@lws256.lu.erisoft.se>
Subject:	Re: (fwd) startup-code
To:	djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date:	Tue, 26 Sep 2000 14:35:27 +0200 (MET DST)
In-Reply-To:	<Pine.SUN.3.91.1000926134604.13268G-100000@is> from "Eli Zaretskii" at Sep 26, 2000 01:51:41 PM
X-Mailer:	ELM [version 2.5 PL3]
MIME-Version:	1.0
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

Eli said:
> 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?

Yes.

> 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?

Yes.

> 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".

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. Currently, mcount.c is polluting the namespace.


Right,

						MartinS

- Raw text -