HP HP-UX Problems
The following are known problems with this platform. (This section has not changed at Version 5.0.0-5.)
Backtrace Problems While Stopped in Some Stubs in 32-Bit Applications
Some versions of the ld linker generate incomplete unwind information for relocation and export stubs. If TotalView is stopped in one of these stubs, the backtrace display can be affected. If you are using HP-UX 11.0, you can partially solve this problem by installing the PHSS_19866 patch, which is available from HP. This patch does not fix the problem in executables or shared libraries already linked with the faulty linker and which were supplied with the system and its compilers.
Backtrace Problems in 64-bit Application
If you are debugging a 64-bit core file, the backtrace does not include the source. All that is present is the strcpy() function where the program received the SEGV. (3260)
Debugging shared libraries
The dynamic library loader on HP-UX loads shared libraries into shared memory. TotalView does not write breakpoints into shared memory because these breakpoints could cause unrelated programs to fail.
If you need to single-step or set breakpoints in shared libraries, you must set your application to load those libraries in private memory. This is done using HP's pxdb command.
pxdb -s on appname (load shared libraries into private memory)
pxdb -s off appname (load shared libraries into shared memory)
For 64-bit platforms, use pxdb64 instead of pxdb. At the present time, the version of pxdb64.exe supplied with HP's compilers does not work correctly and you must install patch PHSS_20122. You can download it from:
ftp://us-ffs.external.hp.com/hu-ux_patches/s700_800/11.X/PHSS_20122
With some versions of the linker after 11.17, using pxdb64 no longer works. This problem has been reported to HP. Contact Etnus support for information about working around the pxdb64 problem. (3218)
NFS filesystems Must Be Hard-Mounted
The debugger interface provided by HP-UX requires that the executable being debugged cannot be on a soft-mounted NFS filesystem.
Problem with Cray Pointers
The HP compiler does not emit a symbol for the "pointee" information for a Cray pointer. For example:
pointer (iptr, ixx())
iptr = malloc(100)
Because no information exists for symbol ixx, you are not able to look at it. You can, however, modify the pointer's type and then look at its contents. For example, you could change the type of iptr from integer to a a pointer such as <real*4>*, dive through it, then add bounds to the type.
Single-Stepping
TotalView does not allow you to step into functions that have not been bound by the run-time linker. If you wish to step into such a function, set a breakpoint at that function and run to the breakpoint.
You can avoid this problem by linking the executable being debugged with the -B immediate option or by calling chatr with the -B immediate option.
