Download pdf Format

Once the Purify and Quantify tracks were built and running
correctly, our next goal was to make the system easier to use. The
typical complaints we received from developers and testers
included:
●
●
●
There was constant instrumentation of the shared libraries.
Quantify output on one HP hardware system did not match the next
developer's output, which was produced on a slightly different HP
system.
Our internal SAS debugger would not work seamlessly with the
systems. (Yes, we have our own debugger, too.)
Ensuring Consistent Results on Different Machines
We addressed each problem as it arose, and inconsistent results between
different machines was the first problem we encountered. The differing
results were caused by the fact that many different varieties of HP
hardware were in use throughout the company. When tech support
informed us about the -use-machine option, we chose one of the many
varieties of HPUX machines installed in house and made that value the
default. This option was added to the Quantify track variables that are
used to build the master executable. All shared libraries and the main SAS
executable are accessed from a global area on the network, so all
developers now run with the same machine type; once the
instrumentation of each shared library was the same for all users, we
could set up a global cache for instrumented modules. We set the cache to
be on the global network and added the -cache-dir option that pointed to
this global area for both the Purify and Quantify builds. Finally, a postprocessing step was also added to our nightly build process to instrument
each shared library after it was built and to place the instrumented image
in the cache. This change allows a user to start working in the morning
with up-to-date, pre-instrumented images. The user no longer has to
watch as each shared library is loaded and instrumented on the first run
each day.
Stopping at Breakpoints When Running SAS with Purify
Another problem was that developers were unable to set breakpoints in
our debugger when running a Purified or Quantified version of the SAS
System. They could run with the debugger and set a breakpoint on
purify_stop_here, but they could not set a breakpoint in a particular
shared library. This problem was caused by the fact that Purify and
Quantify munge the shared library name by appending a constant string to
the image name that is given to the instrumented shared library. For
example, if the shared library name is sasxfs, the instrumented shared
library name looks something like sasxfs_pure_q7152_420_B1020. The
images loaded by the system and therefore by our debugger are the
instrumented shared libraries. Our debugger did not know about this name
aliasing, so we worked with the debugger developers to add a global
variable that is built with the SAS System that contains the appended
value. When the debugger loads SAS, it now looks for this global variable;