[fpc-devel] profiling on win32

[Peter Vreman]

>>> Did someone manage to enable profiling on win32?
>>> I linked with libc.a, libgmon.a, libgcc.a and libkernel32.a from cygwin
>>> but
>>> it fails on startup.
>>> If I start the -pg compiled program I see:
>>>
>>> monstartup: out of memory
>>>
>>> Then program runs without problems, and at the end I see a couple of
>>> access
>>> violations from gprof libraries code:
>>>
>>>       2 [main] testprogram 1316 handle_exceptions: Exception:
>>> STATUS_ACCESS_VIOLATION
>>>     242 [main] testprogram 1316 open_stackdumpfile: Dumping stack trace
>>> to
>>> testprogram.exe.stackdump
>>>
>>> I couldn't find anything on fpc website: faqs read "Profiling is
>>> supported".
>>> I had it working on linux but I'm not able to have it working under
>>> win32
>>
>> FPC can link to gcc under Windows, but doesn't use the runtime of gcc
>> under win32 (mingw or cygwin), but directly accesses kernel32 and
>> user32.
>>
>> Usually this is a blessing, but probably the profiler is very tied to
>> this.
>>
>> What probably should be done is to properly initialise libc and reroute
>> memory handling to libc's mmalloc. This could impact the profiling
>> result
>> maybe though.
>>
>> Note that on windows there are at least three "c" frameworks to link to
>> (Microsofts msvcrt, mingw, cygwin), so any solution will always be
>> windows
>> specific.
>
>  Everything is all right now with Peter fix (it was Peter, wasn't he? I
> can't
>  remember now).
> I sent a mail to the ML saying it worked but I think it didn't arrive :)
> I only needed to add libgmon.a, libgcc.a, libc.a and libkernel32.a from
> cygwin to fpc bin directory.
> In the mail that didn't arrive I wrote:
> Why don't add gprof.exe, libgmon.a, libgcc.a, libc.a and libkernel32.a
> from
>  cygwin to win32 distribution of fpc?

That will make the distribution even bigger. It is already large enough.
Also it creates versioning problems that already sometimes happen with the
cygwin1.dll we distribute.