Rational Quantify 4.5.1 Solaris
Contents
- Bug fixes and compatibility with OS patches.
- Support for Solaris 7 and Sun Visual
Workshop 5.0.
- This is the last release to support
SunOS 4 and HP-UX 9.x. Apex Ada and
Java are no longer supported.
- Bug fixes and compatibility with OS patches.
- Support for gcc 2.8.1
- New product installation and licensing.
Supports FLEXlm based licensing when
installed as part of RSDSU.
- Support for Apex 3.0.0 Ada and C++ on
Solaris and HPUX.
- Please see the Restrictions and Known Issues
section below for important notes about using
Purify with Apex.
- bug fixes
Miscellaneous
- Support for V8+ object files
This release supports EM_SPARC32PLUS
object files which contain instructions
from the SPARC V9 architecture.
- Solaris 2.6 support
- Extended compiler support
This release supports the Sun Workshop
C 4.2 and C++ 4.2 compilers.
- Purela query script
This release contains a new utility,
purela_show, which generates simplified
reports from license and usage data
maintained in a standard or aggregate
PureLA database.
Support for Solaris 2.5.1
Support has been added for the Solaris 2.5.1
operating system.
Pure License Advisor (PureLA)
The "Simple License" advisor, PureLA, offers a number of new features to further simplify the administration of licenses to Rational Software products. See the Installation Guide for more details.
Miscellaneous
- Updated -use-machine option
When specifying a machine type for which to
collect performance data, the clock rate may
now also be specified. This avoids the need
for Quantify to measure the speed of the
machine on which it is currently running.
The new syntax is:
-use-machine<machine>:<speed>Mhz
e.g. -use-machinesparcstation_5:60MHz
Quantify has been tested with Solaris
versions 2.4, 2.5, 2.5.1, 2.6 and 2.7
on SPARC platforms.
Quantify has also been tested on normal and
V8+ SPARC programs on the UltraSPARC.
Quantify has been tested with the
following compilers:
- Sun Workshop C and C++ 4.2 and 5.0
- SPARCWorks C and C++ versions 3.x
- SPARCWorks f77 versions:
3.0
- GNU gcc and g++ versions:
2.5.8, 2.6.3, 2.7.2, 2.8.1
Quantify supports these threads packages:
- The native Solaris libthread library.
- The Solaris Pthreads library, libpthread.
- Transarc DCE threads.
- gcc/g++ 2.8.1 is supported, but there are
known problems with C++ shared libraries
containing gcc/g++ produced objects files
containing exception handling code.
- This release of Quantify does not
support Solaris 2.3.
- Because of operating system differences,
programs instrumented on one version of
Solaris may crash or generate incorrect
results if run on a different version of the
operating system.
- Quantify does not support use of the
LD_PRELOAD environment variable.
- The SPARCWorks incremental linker, ild, is
automatically disabled by Quantify
due to an incompatibility with file naming
conventions.
- Calls to dlclose() that would cause the
library to be unmapped can cause qv to
incorrectly attribute data to the improper
functions. Quantify intercepts calls to
dlclose() and prevents libraries from being
unmapped.
- Under most window managers, if a non-explicit
focus policy is used, qv can steal the focus
from a non-qv window. Click on the window
title to reestablish proper focus.
- Under twm and tvtwm, Quantify dialogs can be
iconified. Once iconified, however, they
cannot be de-iconified and qv will no longer
respond. You should avoid iconifying dialogs
under these window managers.
- Under olvwm, dialogs are sometimes placed on
the wrong virtual screen unless qv is running
on the main virtual screen. This is fixed in
the latest version of olvwm.
- A bug in the libX library shipped with
OpenWindows 5.3 causes X client programs to
either hang or crash when the display refuses
a connection. This problem is especially
notable when displaying to HP-UX displays.
This bug effects all X programs (for example,
xterm) and is not a Quantify bug.
To workaround this problem, ensure that
display permission for the client machine has
been granted on the X server machine, e.g.,
% xhost + machineName
- There is a bug in version 3.3 of the
OpenWindows X server shipped with Tadpole
SPARCbooks. The server loses track of a
client application's Graphics Contexts (GCs)
after the first time the GCs are used. As a
result, among other things, buttons and menus
of client applications which are supposed to
be greyed out don't look greyed out.
You can see the same bug in other X
applications such as xterm. In xterm, use
control-middle-click in the xterm window to
pop up the xterm VTOptions pop-up menu.
Notice that the menu item "Show Alternate
Screen" (close to the bottom of the menu) is
greyed out. Now let go of the menu (without
selecting anything), and popup the menu again.
Note that the same menu item is no longer
greyed out.
- The Quantify GUI menus and buttons become
inaccessible if either the NumLock or
ScrollLock key is activated. The workaround
is to switch them off, or add the following
line(s) to your $HOME/.Xdefaults file.
! Ignore the NumLock and ScrollLock keys on
! mouse buttons
Quantify*ignoreModifierMask: Mod3|Mod2
This second workaround will take effect for
a new Quantify viewer after you restart
your X-session or run a command like
'xrdb -merge $HOME/.Xdefaults'.
- FORTRAN routines with multiple entry points
are not supported when compiled -g.
- FORTRAN routines with formatted READ or WRITE
statements which use the END or ERR
specifiers are not supported when compiled -g.
- The GNU gcc extensions are not tested against
Quantify. Most gcc extensions will
probably work fine. Known limitations at
present include problems with nested functions
(e.g.: making a pointer to a nested function
and attempting to call through it will not
work).
- Customers using unsupported threads packages
should contact Rational Software technical
support (support@rational.com) to ensure
compatibility.
- When running threaded programs, setting the
LD_BIND_NOW environment variable to a non-null
value simplifies the resulting callgraph and
excludes time spent in the dynamic loader.
When LD_BIND_NOW is set, the runtime linker
processes all relocation prior to the start of
the program. See the "Linker and Libraries
Guide" in the AnswerBook.
General Limitations
- The Apex runtime raises certain exceptions
using signals which the runtime traps and
turns into normal exceptions (like
CONSTRAINT_ERROR). This transformation
manifests in Purify as a SIG message and
does not usually mean the program under test
raised any signals itself.
- Purify Apex, PureCoverage Apex, and Quantify
Apex may not be used to instrument non-Apex
applications. Non-Apex libraries and object
files that participate in an Apex link are
fine, but these tools may not be used in a
non-Apex environment. To instrument non-Apex
applications, you need the non-Apex versions
of Purify, PureCoverage, and/or Quantify.
Source Annotation Limitations
- If you have already installed Apex 3.0.0 and
built your application, you will need to
recompile after installing Purify Apex,
Quantify Apex, or PureCoverage Apex in order
for these tools to report source annotations
on a per line basis. The Apex compilers do
not generate some of the debugging
information required by these tools unless
the tools are installed.
- If you modify a source file in such a way
that Apex determines it is not necessary to
generate new code (e.g. by only adding
comments), source annotations from Purify
Apex, Quantify Apex, and PureCoverage Apex
will be incorrect. You must force a
recompilation of the modified source file so
that new debugging information is generated.
- Source annotations are not provided for
generic instantiations.
- Purify Apex does not have access to variable
name information from Apex, and therefore will
not display the names of local variables in
error reports.
- If while using the Apex Ada compiler to
generate code, you see a message of the form:
!!! Unable to write Lines to Offset Mapping: CONSTRAINT_ERROR
The compiler will fail to generate source
information for the associated Ada file
that is consumable by Purify Apex, Quantify
Apex, and PureCoverage Apex. In this case,
no source annotations or line level coverage
and performance data will be available for
functions in the affected file.
Debugging
- Single stepping through instrumented code at
the instruction level though prolog and
epilog code may not work correctly.
- The debugger may report the values of
variables incorrectly in instrumented code
if those variables are held in registers.
- If you wish to call Purify, PureCoverage, or
Quantify API functions from inside the
debugger while debugging Ada code, you can
always invoke the API functions using their
C names. If the corresponding Ada API function
is linked into your application, you may use
the Ada names instead.
For example, if you are using package
Puretools.Purify in your application, then you
can use the following debugger command:
>p Puretools.Purify.What_Colors(my_address, nbytes)
If you are not using the Ada wrappers in
your code, then you would invoke:
>p purify_what_colors(my_address, nbytes)
The C function names and signatures are
available in the C/C++ reference sections
for each tool. See Help:Manuals:Rational
Apex/Pure Integration Manuals.
- When using Purify's JIT debugging feature
with the Apex debugger, Purify may give up
waiting for the debugger to attach if it
takes more than 3 minutes. To force Purify
to wait longer, set the
PURE_JIT_DEBUG_MAX_WAIT environment variable
to the number of seconds you want Purify to
wait for the debugger to attach.
Using rcc/RCC directly
- If you use rcc or RCC outside of the Apex
GUI or shell environment, you will need to
add the appropriate FlexLM license file to
your LM_LICENSE_FILE environment variable.
You should add the license file where your
Quantify licenses were placed during
Installation.