|how does purify work? firstname.lastname@example.org (2000-08-04)|
|Re: how does purify work? email@example.com (Ben Pfaff) (2000-08-05)|
|Re: how does purify work? firstname.lastname@example.org (Chris F Clark) (2000-08-05)|
|Re: how does purify work? email@example.com (2000-08-05)|
|Re: how does purify work? Martin.Raabe@WindRiver.com (Martin Raabe) (2000-08-05)|
|Re: how does purify work? firstname.lastname@example.org (2000-08-05)|
|Re: how does purify work? email@example.com (2000-08-10)|
|Re: how does purify work? firstname.lastname@example.org (Venkatesha Murthy G.) (2000-08-10)|
|Re: how does purify work? email@example.com (Chris F Clark) (2000-08-13)|
|From:||Chris F Clark <firstname.lastname@example.org>|
|Date:||5 Aug 2000 21:31:26 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
> Once upon a time Purify did work for vxworks. It would be a very nice
> tool to have and it seems very odd that there's no product with
> equivalent functionality.
> If one wanted to build a Purify like tool, does anyone know how it
> would be done? I don't really understand what it does and haven't
> found much related info.
> [Doesn't it stick extra code into your program to audit all of the
> allocation, freeing, and pointer references? Dunno if it hacks the
> source or rewrites the object. -John]
There are (at least) 5 ways to implement Purify like tools.
1) Purify (and Third Degree--the tool I maintained for Compaq for a
while) work by taking each object file (either the .obj or the
.exe) apart sticking in extra instructions that monitor when the
program does each "interesting" thing (allocate, deallocate,
reference through a pointer, initialize a variable, whatever).
The extra instructions then store bits of information away in the
tool's database (essentially a big array of bits denoting the
status of each memory location as allocated and/or initialized) and
check that database to report problems.
2) Insight++ does roughly the same thing but takes the source code
apart and inserts source code to do the same thing.
3) Centerline does roughly the same thing, but implements it by
interpreting the source code.
4) It can also be done by interpreting the instruction stream. Sun's
tool Shade does something like this (though not to implement
5) It should also be possible to do it via a "pointer swizzling"
technique, where only the libraries are replaced. This would be
like the way ObjectStore implements object-oriented databases. In
this case, only the run-time library routines like malloc and free
are modified. Instead of returning real pointers, they return
"fake" values that are guaranteed to cause "segmentation faults" or
"access violations" (or some other trappable signal). The tool
also inserts its own signal handlers (possibly by modifying the
signal and program startup runtime routines). The signal handlers
wait for the trappable signals and then use them to detect the
memory accesses to be watched and use that to perform the
annotation and also substitute the correct action.
My guess is that the above are ordered approximately by how fast they
would execute--technique 1 being fastest and either 4 or 5 being
slowest. (The speed of 5 would depend on how often the faults
occured. If seldom, it might be fast.)
Either technique 2 or 3 is probably the simplest to implement if you
have only 1 source language to deal with.
Note, if you use technique 1, you have to be careful as the Purify
folks staked out the territory pretty well with patents which they
Hope this helps,
Chris Clark Internet : email@example.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
Return to the
Search the comp.compilers archives again.