From: Martin Stromberg 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: from "Eli Zaretskii" at Sep 26, 2000 01:51:41 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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