Release notes for Quantify 5.2 HP-UX
Contents
========
o Changes from previous releases
o Supported systems
o Restrictions and known issues
New In This Release
===================
- Bug fixes and compatibility with OS patches.
- This release uses a new FlexLm based
licensing. Read the new installation
guide before installing the product.
Use rs_install instead of pure_install
for the installation.
- This is the last release to support
HPUX 10.01 and HPUX 10.10.
New In Quantify 5.1
===================
- Bug fixes and compatibility with OS patches.
- HP-UX 9.x is no longer supported.
- Support for Cygnus 98r2 compilers
New In Quantify 5.0.1
=====================
- Bug fixes and compatibility with OS patches.
- This is the last release to support
HP-UX 9.x. Apex Ada is no longer
supported.
New in Quantify 5.0
===================
- This version supports "wide mode" applications
on HPUX 11.00: programs using 64-bit pointers,
compiled with the option +DA2.0W. See below
for important notes about 64-bit development.
- Bug fixes and compatibility with OS patches.
New in Quantify 4.4
===================
- Bug fixes and compatibility with OS patches.
- New product installation and licensing.
Supports FLEXlm based licensing when
installed as part of RSDSU.
New in Quantify 4.3
===================
- Support for Apex 3.0.0 Ada and C++ on
Solaris and HPUX.
- bug fixes
New in Quantify 4.2
===================
- bug fixes
New in Quantify 3.1.1
=====================
- Updated Japanese translations
This release contains improvements
in the Japanese translations for the
Online Help.
New in Quantify 3.1
===================
Miscellaneous
-------------
- HP-UX 10.30 support
This release supports HP-UX 10.30,
including kernel threads.
- Support for PA-RISC 2.0
This release supports PA-RISC 2.0 object
files.
- Extended compiler support
This release supports the HP aCC
compiler.
- 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.
New in Quantify 3.0
===================
Support for HP-UX 10.20
-----------------------
Note: code compiled specifically for the
PA2.0 processor is not supported. Such code
will be generated by default on PA2.0 systems.
Use the compiler option +DA1.1 to disable
this.
Support for the HP ANSI C++ compiler "aCC"
------------------------------------------
Quantify supports the aCC compiler from HP.
There is a patch to get from HP to be sure
this will work. See the "Restrictions and
Known Issues" section for more details.
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=:Mhz
e.g. -use-machine=sparcstation_5:60MHz
- Updated HP machine models
Models for the new superscalar HPPA 7300 and
8000 processors have been incorporated into
Quantify, allowing it to more accurately time
your code on these machines.
In addition, Quantify's database of machine
configurations has been updated to include the
latest available data from HP.
==================================================
Supported systems
=================
Operating system and Hardware
-----------------------------
Quantify has been tested with HP-UX
versions 10.01, 10.10, 10.20, and
11.00 from Hewlett Packard.
This is the last release to support
HP-UX versions 10.01 and 10.10.
Quantify also supports 64-bit wide-mode
programs on HPUX 11.00. A wide-mode program
is one that uses 64-bit longs and pointers,
built with the compiler option "+DA2.0W."
Compilers
---------
Quantify has been tested with the
following compilers:
- Bundled cc.
- ANSI cc.
- C++.
- aCC.
- GNU gcc and g++ versions, through version 2.8.1.
- Cygnus GNUpro v.98r2
- f77.
See the "Restrictions and Known Issues"
section for more details.
Threads
-------
Quantify supports these threads packages:
- DCE threads (either libdce or libcma).
- HP-UX kernal threads.
==================================================
Restrictions and Known Issues
=============================
General
-------
- Instrumented programs now always use
immediate binding for the initial load of
shared libraries and for any dynamic loads
using shl_load().
This change was made due to a problem in HP
dld patches from June 1998 for HPUX 11.00
and August 1998 for HP-UX 10.20, which
caused the instrumented application to hang
after a call to shl_load(). One known
instance of this problem occurs when
you use getservbyname() because it loads
network protocols using shl_load().
Linker and dld patches available after 3/99
don't have this problem. If the user has
an earlier patch, an upgrade is strongly
recommended.
- Quantify will not run on short
(14-character) file systems.
- Operating system revisions below 10.01 are no
longer supported.
- The PA-RISC 1.0 CPU is no longer supported.
- Profile Based Optimization is not supported.
- Applications which link to over 50 large
dynamic libraries may experience reduced
startup times by setting the runtime option
-lazy-dld-maps=1.
Using 32-bit vs 64-bit Quantify
-------------------------------
Quantify supports both 32- and 64-bit
development. "Wide" mode, or 64-bit
applications are those compiled with
the +DA2.0W option - apps using 64-bit
pointers. "Narrow" mode applications
are traditional 32-bit programs.
Quantify ships in 2 configurations,
one supporting wide mode and the
other supporting narrow. Both can
be installed on the same file
system, but the 64-bit version
can only be used on 64-bit HP-UX
11.x systems.
If both install directories are in
your path, Quantify will auto-select
the correct wide or narrow mode
version, in most situations (see
below for limitations). For example,
you can install two versions of Purify:
purify-5.1-beta-H1-hpux (32-bit)
purify-5.1-beta-P1-hpux (64-bit)
(Beta and proto release with H
in their name are 32-bit release.
P signifies a 64-bit release.)
Or, for a final release:
purify-5.1-hpux (32-bit)
purify-5.1-hpux64 (64-bit)
If the two install directories are
in your path, then running "purify"
will automatically select the
correct version, based on the type
of program you are linking. The same
is true for Quantify.
Even if only one install directory
is on your path, auto-selection will
occur if both versions are properly
installed: Running pure_install on
each version will prompt you for the
location of the other product.
If you already have your licenses
installed and do not choose to run
pure_install, you can set up this
connection between the two install
directories by running the script
"pure_link_32_64" in each install
directory:
% cd purify-5.1-hpux
% pure_link_32_64
% cd purify-5.1-hpux64
% pure_link_32_64
Auto-selection only works between 32-
and 64-bit Quantify from 5.0 onwards.
In some situations, auto-selection
does not have enough context to tell
which version (32 or 64-bit) you need.
This is true for the options:
-help
-printhomedir
-test-license
-version
In these cases, Quantify defaults to
the 32-bit version unless you
explicitly specify what you want,
using the new -ptr64 and -ptr32
options:
% purify -ptr64 -test-license
% quantify -ptr64 -printhomedir
% purify -ptr32 -version
% quantify -ptr32 -help
Failure to include -ptr<32|64> in these
cases may yield the wrong information.
For example, you may get the product
home directory for the 32-bit product
when you wanted the 64-bit product.
These options are NOT necessary during
normal instrumentation and viewing
operations:
% purify cc -g -o foo foo.o
% quantify -view my_app.qv
If you attempt to use the 64-bit Quantify
using -ptr64, or by having it on your
PATH first, on a non 11.x systems,
execution will fail. It only runs on
HP-UX 11.x and later.
Because of a defect in auto-selection,
auto-selection does not occur when
using "-nolink". You must use -ptr64
or -ptr32 to ensure the correct
version is used:
% quantify -ptr32(or -ptr64) -nolink ld mylib.a
- Restrictions on the HP-UX 11.00-wide
(64-bit) version of Quantify:
- Static data checking is not supported.
- Using Quantify with old versions of
the HP-UX linker may cause the install
test to fail with an error from the
linker saying the "+nodynhash" option
is not recognized. You should obtain
a newer linker from HP. This option
is support by 64-bit linkers from
07-Jan-1999 and later.
You may also workaround this problem
by include the following in your
PUREOPTIONS environment variable:
-force-no-dynhash=no
The default setting of this option
(to "yes") is used to workaround an HP
bug in newer linkers.
- Shared-library "fini" sections (static
destructors) do not run.
- shl_unload and dlclose are not
implemented. When a program attempts
to unload a shared library, the call
will appear to succeed, but the
library will not actually be closed
or unloaded. Also, C++ "static
destructors" are not run for the
library.
- There is a bug in strlen in the 64-bit
libc which causes the example program
"hello.c" to get numerous UMR's instead
of only one, as you might expect.
- Quantify will not report system call
time spent inside brk or sbrk.
- When a Japanese locale is specified using the
LANG environment variable, instrumentation of
archive libraries may fail with the message:
Error: Child process exited with status = 1.
This is caused by an 'ar' failure in this
locale. A workaround is to unsetenv LANG
before instrumenting.
Data Collection
---------------
- Calls to shl_unload() that would cause the
library to be unmapped can cause qv to
incorrectly attribute data to the improper
functions. Quantify intercepts calls to
shl_unload() and prevents libraries from
being unmapped.
Annotated Source
----------------
- The C compiler (cc) does not include full
source file pathnames when a file is compiled
-g. In this case, Quantify first attempts to
find these source files in the directory of
the executable. If the source is not
available, Quantify then searches the
directories in the value of the -user-path
option. If it is unable to find the source
file after this search, a file dialog is
presented for the user to locate the source
file.
User Interface
--------------
- 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 vuewm, the window manager fails to
update the border of the window that has
current focus after a menu has been used.
Click on a window to reestablish proper
focus. Alternatively, set the following X
resources in your .quantify.Xdefaults file:
vuewm*enforceKeyFocus: False
*OI*wmIgnoresPPosition: True
- Under vuewm, de-iconifying one window from a
different window on a different virtual
screen makes a copy of the de-iconified
window on the current virtual screen as well
as de-iconifying the window on the previous
virtual screen.
- 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'.
Compilers
---------
- 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).
- Quantify supports the aCC compiler from HP
but there is a required patch: for HP-UX
10.01 through 10.10, use PHSS_14507. For
HP-UX 10.20, use PHSS_17689. For HP-UX
10.20 you also need PHSS_17225.
- When using the aCC compiler from HP, time
spent in constructors will be counted at
function granularity, even if compiled with
the -g option. Also, time spent in
constructors can be assigned to three
separate functions; for a class called
MyClass the time might be split among the
functions MyClass::MyClass,
MyClass::MyClass%1, and MyClass::MyClass%2.
The true time is the sum of these times.
- C revisions 9.61 through 9.65
- These compilers generate incorrect
debugging information for some functions.
Programs compiled using these compilers may
not be debuggable after translation.
In this case Quantify may produce a
message beginning "Failure relocating..."
Additionally Quantify may not be able
to attach performance information to specific
line numbers in such cases.
HP patch PHSS_4923 corrects this problem.
- Exception handling
g++ 2.7.2 exceptions are not supported.
Debuggers
---------
- XDB & Softdebug
- Use /quantify_xdb to
invoke xdb on an instrumented program.
- An instrumented program receives a signal
18 (death of child) during its
initialization. Place "z 18 sir" in your
~/.xdbrc file to suppress this warning.
Failure to suppress the warning will
sometimes cause xdb to fail.
- XDB, when debugging a program that uses
shared libraries, reads the symbol table
from /lib/dld.sl. However, Quantify
has changed your program to use an
instrumented version of dld.sl. The
symptom of this mismatch is the message:
Wait...loading shared-library map tables.
xdb panic: Mapped addresses for dld
overlap text segment for dld
There is a simple workaround for this
problem and we've implemented it in the
shell script /quantify_xdb.
Whenever you use xdb on an instrumented
program use this script to invoke xdb.
- Typing ^C while running an instrumented
program under xdb requires caution. There
is a high probability that the interrupt
will occur inside the code Quantify has
added to your application. If this is the
case, you must single step or set a
breakpoint and continue before you attempt
to call any subroutines (the Quantify
API is an example).
- The XDB single stepping command, 's'
sometimes fails to find the next source
line. When this happens, usually near a
subroutine call, program execution
continues until the next breakpoint. The
'S' command is always reliable.
- DDE - Distributed Debugging Environment
- The DDE debugger at release 2.10 has been
used with instrumented programs. The shell
script: /quantify_dde
implements one of the workarounds.
- Instrumented programs get a SIGCHLD signal
at program initialization. One workaround
is to just hit "go" when the program stops.
The following commands added to a .dderc
file also help:
prop system -on
alias `after_debug delete intercept signal SIGCHLD; \
prop system -off; \
breakpoint -in main -entry -exit; \
go
Old Style Fixups
----------------
Quantify does not support a type of
relocation information known as "old style
fixups". These were generated by HP-UX system
software before release 3.0. If Quantify
detects old style fixups the message:
Object file has incompatible format
(may be older than HPUX 3.0)
is generated. We have seen this problem with
HP's libsql.a and some of Oracle's Oracle6
libraries.
There is a simple workaround. Given a problem
object module (or modules) the workaround is to
have /bin/ld build a new object module. Suppose
the old object modules are called `foo.o' and
`bar.o'. Issuing the command:
% ld -r -o new_foo.o foo.o
% ld -r -o new_bar.o bar.o
or
% ld -r -o foo_and_bar.o foo.o bar.o
would generate a new object module where the old
style fixups have been removed.
In the case of an archive file the following
script will create a new archive given the full
pathname of the original:
#!/bin/sh
# Remove old fixups from an archive.
# Supply original .a name as first argument.
cd /tmp
lib=new_`basename $1`
ar x $1
rm -f $lib
for member in `ar t $1` ; do
ld -r -o _$member $member
ar q $lib _$member
rm $member _$member
done
echo Created `pwd`/$lib
Threads
-------
- Customers using unsupported threads packages
should contact Rational Software technical
support (support@rational.com) to ensure
compatibility.