This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc support for memory debuggers (operator delete) ?


I would suggest simply overriding the standard operator delete, obtain
the call stack within it, and map the returned addresses to source files
and lines.  This is quite doable on a number of modern systems, and with
some cleverness works fast enough that the program won't slow down too much.

We have recently written a small profiler library you can LD_PRELOAD
into any program.  It produces hierarchical performance and memory
allocation profiles; the performance side looks a lot like gprof output,
the memory side gives similar statistics for allocs.   At present it
works only on linux, extension to other platforms is easy (= we know how
to do it, it's just a question of time and interest).

My background is that in our environment a tool that requires intrusive
instrumentation (even if it's just to recompile with different options)
is useless.  It's got to pretty much work by LD_PRELOAD or a similar
mechanism, and with code you can't rebuild.  But then, 99+% of our code
is in dynamically loaded shared libraries; we don't have or care about
statically linked programs.  YMMV.

//lat
-- 
The man who doesn't read books has no advantage over
the man that can't read them.  --Mark Twain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]