Hi Przemek,
If you try to enable memory statistic in shared
binaries using harbour.dll then it will not work
in such way. In MS-Windows DLL is not shared library
like in other systems but complete executable which
only public some entries. It means that any internal
bindings cannot be overloaded :-(
But it should work for static builds. Here the only one
problem is caused by the fact that it's library. In the
past original version was using fm.o (obj file) and
linking was much easier because it was enough to add it
to linked object list. It was converted to library and
now looks nicer but it creates additional problems.
You have to know dependencies used by your linker and
Harbour core code and insert FM lib after 1-st request
to some of FM module functions and before HVM lib.
It should be enough for Windows linkers. For GCC I had
to generate temporary .c file with request to HB_FM_STAT
which is compiled and linked with final binaries.
It's a classic example where sth looking nicer may create
more problems. Libraries are used by linkers in different
way then object files.
My fears exactly (but worded much more precisely :)
Przemek, do you see any chance that you could
somehow convert this to a runtime option? no hurry,
it's enough if you say whether it's somewhere on
your table :)
I looked at this modification and it's not hard to implement
if hb_getenv_buffer() will work inside start up code (I do
not know if all C compilers will support it) so memory statistic
can be enabled by environment variable. I do not see any protable
way to implement RT application switch for it. Maybe it can
be done for some chosen C compiler for which is known how to
extract parameters from their internal structures before
main()/WinMain() is executed.
An envvar will suffice. FM STATS is a tracing tool
and normal app flow tracing (HB_TRACE) is already enabled
using envvars, so this is not without precedent in
Harbour, and someone wanting to use it would most
probably able to set it up (this means Harbour and
3rd party developers in the first place). F.e. developers
would simply have this envvar set on development
machines and naturally not set on end users', so the
app would just behave as expected in both environment,
without any need to rebuild or recompile. Seems very
natural to me.
The modification is rather simple but it will be necessary to
reorganize current code to keep support for compilation without
any FM statistic and FM statistic always enabled. Just simply
more #IFs with replicated code if we do not want to introduce
some dummy instructions.
Well, IMO (and other opinions are of course welcome),
it should be enough to let this be controlled only
by the envvar. Part of the goal would be to avoid
as much of the current mess regarding this switch
in both make systems. If we could get rid of this,
it would make things a lot simpler and cleaner IMO.
[ It would even be a gain, as for most developers
building and maintaining two parallel Harbour
build (one with FM STAT and one without) is usually
not an option, so I either expect most ppl to
simply slip through possible memory corruption
problems, and another smaller part using an
unnecessarily slow app full time. Neither is very
ideal. ]
I'll make it when I'll find some time for it.
Many thanks.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
