Date: Sun, 25 Nov 2001 14:25:47 -0500
Message-Id: <200111251925.fAPJPlB21198@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <3C013F37.F451C083@phekda.freeserve.co.uk> (message from Richard
	Dawe on Sun, 25 Nov 2001 18:57:59 +0000)
Subject: Re: Building a profiled version of libc
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1011119103715 DOT 8761F-100000 AT is> <3BF97E29 DOT 39FC7C7E AT phekda DOT freeserve DOT co DOT uk> <3405-Tue20Nov2001082315+0200-eliz AT is DOT elta DOT co DOT il> <3C00F797 DOT 88E8AA45 AT phekda DOT freeserve DOT co DOT uk> <7263-Sun25Nov2001182924+0200-eliz AT is DOT elta DOT co DOT il> <3C013F37 DOT F451C083 AT phekda DOT freeserve DOT co DOT uk>
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


I don't think you can do profiling in a dxe because it isn't using the
mcount routines from the libc the application uses.  Even if you get
it working, either the mcount data from the dxe isn't written out (no
exit handler) or worse it is written out and overwrites the data from
the application.

I think it's best to just not try to profile dxes.  If we wanted to
actually support something like this, we'd have to turn libc.a into a
shared library, so that we could "link" dxes to it at runtime.  Since
that causes its own problems, I don't think it's worth it just to
profile dxes - you can link the dxe code directly into your app if
you're profiling it.