Re: how does purify work?

Someone asked:
> 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.
>
> thanx
> [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
      Purify functionality).


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
have pursued.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.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 comp.compilers page.
Search the comp.compilers archives again.