This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: DJ Please read - profiling
- To: robert dot collins at itdomain dot com dot au
- Subject: Re: DJ Please read - profiling
- From: DJ Delorie <dj at delorie dot com>
- Date: Thu, 3 May 2001 17:30:30 -0400
- CC: cygwin-developers at cygwin dot com
- References: <000801c0d415$96ccf4b0$0200a8c0@lifelesswks>
> I recall you have done serious work on profiling cygwin? I don't
> have dejagnu running here, nor _any idea_ on how to profile cygwin.
To use gprof, you need to build cygwin as a static library with -pg.
That in itself is tricky, because you first have to replace malloc
with some other implementation so that it doesn't recurse (cygwin
calls the user's malloc, which *is* cygwin's malloc if you link
statically). You also have to rewrite all the startup code to work in
a non-dll situation. It's not easy to get cygwin to run this way, and
expect to end up with a useless mess when you're done profiling.
The next step is the profiler itself - you can use gprof, but the
granularity is pretty bad for quick-lived things like cygwin. I wrote
something that single-stepped the program using the debug API and
built a profile from that; you'd have to ask Chris if I can publish
it, assuming it still works. It (my profiler) should work with cygwin
as a DLL, so that makes things easier, but programs run about 1000
times slower :-( and you have to manually specify the range of
addresses you want to profile. You can, however, profile individual
functions via OutputDebugString controls to the profiler.
I don't remember if my profiler infers call graph counts or if you
have to build cygwin1.dll with -pg. I think it infers the graph.
I will gladly impart my wisdom and experience in detail if someone is
willing to validate what still currently works and write up a page for
cygwin.com.
You don't need dejagnu at all, unless that's what you're profiling.