Date: Wed, 25 Apr 2001 13:17:44 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Fixed core dumper in dpmiexcp.c
In-Reply-To: <4.2.0.58.20010425111557.0178b2e0@ics.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.1010425131407.24985A-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 Wed, 25 Apr 2001, Pierre Muller wrote:

> >I was thinking along the lines of providing the modified dpmiexcp.c (and
> >maybe a modified crt0.S) in this separate library.  If you say something
> >like "gcc foo.c -lcore", these modified versions are linked in instead of
> >the stock ones in libc.a.
> 
>    Doesn't this need a hack to gcc to load the modifed crt0.o
> instead of the ordinary one?

You are right, crt0.o is not in the library.  Which means sbrk cannot be 
easily replaced without modifying crt0.S.

>    I thought at least that there is some special code in gcc for the profiling
> that also needs a special gcrt0.o startup file.

gcrt0.o simply initiliazes the counters used for profiling.  It is linked 
instead of crt0.o when you use -pg; the necessary magic is in specs.  
gcrt0.o is generated from the same crt0.S, by assemblying it with a 
special -D switch.

So GCC doesn't have much to do with this issue.