|
From: Josef W. <Jos...@gm...> - 2004-02-18 16:20:14
|
On Wednesday 18 February 2004 16:10, Doug Rabson wrote:
> On Wed, 2004-02-18 at 14:34, Nicholas Nethercote wrote:
> > That's going to degrade the effectiveness of the various tools by
> > different amounts. For example, Memcheck/Addrcheck will not give errors
> > for heap-block overruns, because it will be tracking addressability at
> > the lower mmap/brk level. And Massif (heap profiler) will be useless.
> > It would be good to give some kind of warning about this.
>
> I wonder if it might be possible to catch thing at the instrumentation
> state, e.g. "hey! thats a call to malloc - substitute this pointer
> instead".
This is only possible if debug info is available. Otherwise there is no
way to detect that a function at a given address is "malloc()" (Or does it
make sense to get some MD5 checksum for a static version of malloc on a given
system at compile time of valgrind and search at runtime for this checksum? I
suppose that relocations can make this impossible).
With debug info, you can catch malloc() calls at instrumentation of first
basic block: make the instrumentation to be a JMP to a replacement function.
This should also work in the shared library case.
Isn't this already done ("kludge") in some cases?
Josef
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|