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

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.

- Raw text -