Preparing source code for HP-UX on Integrity servers

How to prepare your source code for HP-UX on Integrity

Native binaries provide the best performance on the Integrity architecture. You can create a native binary by compiling on Integrity. HP-UX 11i on Integrity is source-compatible with HP-UX 11i on PA, provided your software is well-behaved and does not use libraries and APIs which have been deprecated and are unavailable on Integrity. Thus, the following subsections outline the steps you can take now on HP-UX 11.x PA platforms to make your source code ready for Integrity. Exceptions are listed in the section Software Which Cannot Be Pre-Enabled on HP-UX 11.x.

Resolve Integrity transition issues

The first, key step in preparing your source code for Integrity is following the porting processes (investigating, planning a port, and performing a port to HP-UX 11.x PA) that are documented in the HP-UX Software Transition Kit (STK). For links to these processes, see Source code transitions.

As explained in Using scandetail and scansummary, you use the scansummary and scandetail file scanners included in the STK to identify transition issues such as API changes in your source code files.

To identify the differences between PA and Integrity that affect your source code or binaries, you need to scan your source code files using the Integrity classification option with the file scanners. For example, to get a summary output report listing only the Integrity transition issues in a particular source code file, run the scansummary tool on the command line like this:

scansummary +C Integrity source_file

For detailed instructions on how to use the file scanning tools and interpret their output, see Using scansummary and scandetail.

Once you have run the file scanners to identify all the Integrity API transition issues in your source code files and have completed a porting plan, follow the porting process (Performing a Port to HP-UX platforms) to resolve the necessary transition issues in your source code. Pay special attention to resolving any Non-critical Non-standard (NcNs) impacts in your source code for APIs that are likely to cause compatibility problems.

If you cannot resolve an API impact that is specific to Integrity, you may not be able to fully prepare your source code for Integrity at this time. In this case, resolve all the transition issues you are able to now, keeping track of the transition issue(s) that require more work later.

Use kernel threads instead of CMA threads

HP-UX CMA threads were based on an early draft of POSIX threads, and there are some significant differences between that draft and the final standard, which is implemented as the kernel threads set of APIs. Like CMA threads, kernel threads allow you to develop multi-threaded applications. However, kernel threads provide finer granularity for optimizing performance in applications that can exploit a threaded architecture, such as Web servers. HP-UX 11.x contains thread-safe libraries for C++, Pascal, math/vector, networking, and the dynamic loader, based on the POSIX 1003.1c standard.

DCE threads are not available for native development on Integrity. For more information on using kernel threads, see the paper Introduction to Kernel Threads in the STK.

Use shared libraries

Native archive system libraries are not provided on Integrity. As you are preparing your software for Integrity, you need to be sure your makefiles do not specify archive system libraries. It is recommended that you use shared libraries even for PA applications which run in compatibility mode on Integrity. Shared libraries have the following benefits:

• Shared libraries avoid binding architecture dependencies into the application. This is especially important for PA applications running on Integrity.
• Defect fixes are picked up automatically when a library is patched.
• The performance difference between archive and shared libraries is decreasing as new run-time architectures are optimized for shared libraries.

Use pstat(2) to read system files

If any of your code reads system files directly, such as /dev/kmem, revise your code to use pstat(2) routines to get system information instead. This is because some system files have different formats on Integrity-based systems. By using pstat(2), information can be retrieved about the following:

• Memory -- static, dynamic, shared, virtual
• System CPU processors
• System processes and messaging
• Disks, swap space, and file systems
• Semaphores

See the pstat(2) man page for more information.

Note
The pstat(2) routines are HP-specific routines and are not available on other vendor platforms.

Make 64-bit applications 64-bit clean

Many operating systems that currently have only 32-bit support, including Microsoft Windows® NT and most UNIX® operating systems other than HP-UX, are available in 64-bit versions for the first time for Integrity. While HP-UX and these other operating systems continue to provide support for 32-bit applications, you may want to take this opportunity to create a 64-bit version of your application. Since HP-UX 11.x already provides 64-bit support, you can make your software ready for 64-bit mode on HP-UX now so you do not encounter as many changes later.

Different data models are used in 32- and 64-bit UNIX computing, including HP-UX. The data model used in 32-bit UNIX computing is called ILP32, meaning that integers, longs, and pointers are all 32-bit data types. The data model used in 64-bit is called LP64, meaning that longs and pointers are 64-bit data types, while integers remain as 32-bit data types. Some existing C and C++ code assumes that integers, longs, and pointers are the same size. Because these assumptions are not true in LP64, some executables have defects when they are compiled for 64-bit mode.

Note
The LP64 data model is the emerging standard on 64-bit UNIX systems provided by leading system vendors. Applications that transition to the LP64 data model on HP-UX systems are highly portable to other LP64 vendor platforms.

Problems can arise, however, when you try to make 32- and 64-bit applications interoperable. The difference in the size of the ILP32 and LP64 data models and in system address space can create problems when data is transferred from a 32-bit application to a 64-bit application or operating system, and vice versa. These differences can adversely affect the sharing of data between applications, sharing of data between an application and the operating system, communication between processes, working with large files, loading processes, and working with graphical interfaces. For more information, see the white paper Interoperability of 32- and 64-Bit Applications on 64-Bit HP-UX, and the comprehensive white paper on 64-bit changes, HP-UX 64-bit Porting and Transition Guide.

If you plan to make 64-bit versions of an application for both HP-UX and Windows NT on Integrity-based systems, you need to be especially careful as you make your software 64-bit clean. The 64-bit version of HP-UX (and most other UNIX operating systems) supports the LP64 data model, but 64-bit Windows NT may use a different data model. Thus, you need to be very clear about sizes and types of integers, longs, and pointers when doing 64-bit cleaning. In particular, be sure to heed all warnings regarding data type problems found while compiling your 64-bit HP-UX and Windows NT application.

If any of your applications will be executed in 64-bit mode, they should be 64-bit clean. Tools to help make your code 64-bit clean include using lint, compiling in ANSI C or aC++, and using the portable header file <inttypes.h>.

The following guidelines help make your code 64-bit clean:

• Use the same source code and header files for both 32- and 64-bit applications.
• Use appropriate data types consistently and strictly. For example, use off_t consistently for file offsets and fpos_t for file positions.
• Use integral types in <inttypes.h>, where applicable, instead of ints and longs.
• Use fixed/scalable width integral types, algorithms, and masks as appropriate. Fixed types remain a consistent size on 32- and 64-bit platforms. For example, use int32_t, defined in <inttypes.h>, if ints and longs should be 32-bits in your application. Scalable types can grow and scale without modification to future architectures, such as Integrity.
• Perform boundary checking on integral type ranges.
• Update 64-bit code in cases where 32- and 64-bit processes share the same memory segment.

Compile on HP-UX 11.x

Finally, you can make most of your source code ready for Integrity by compiling it on an HP-UX 11.x PA system. The Integrity compilers are compatible with the PA-based HP-UX 11.x compilers. HP provides the C, ANSI C++, COBOL, HP Fortran, and Java compilers for HP-UX on Integrity. The C, ANSI C++, and Fortran compilers on Integrity generate both 32- and 64-bit code, with 32-bit code as the default, as it is in PA compilers. The Cfront C++, Fortran77, and Pascal compilers have been obsoleted for Integrity, so you should plan to move any code off them now.

The C compiler and C Lint in HP-UX 11.x have a +M1 option that you can use to identify compiler and linker options that either change or are obsoleted for Integrity.

Optimization is increasingly important on Integrity. The Integrity compilers use advanced optimization techniques based on the current PA compilers. Therefore, you should experiment with higher levels of optimization and Profile Based Optimization (PBO). Optimizing now not only exposes defects in your code, but it also results in a faster PA application.

Software which cannot be pre-enabled on HP-UX 11.x

Most source code can be made ready for Integrity now on HP-UX 11.x PA platforms. However, software with either assembly language code or kernel-dependent code, or any software that is sensitive to either the different run-time architecture, the new 32-bit object file format, or the new debug format of Integrity cannot be pre-enabled now.

This section describes these exceptions.

Assembly language code

You cannot pre-enable applications with assembly language code because the new Integrity instruction set is different from the PA instruction set. If you have any assembly language applications needing to be compiled on native Integrity, you must re-code and performance tune the assembly language source.

Kernel-dependent code

The HP-UX kernel has changes related to Integrity support. If your code is kernel-dependent (for example, kernel drivers), you cannot pre-enable it on HP-UX 11.x.

Software sensitive to the different run-time architecture

The Integrity run-time architecture is different from that on PA. If you have software that is sensitive to the run-time architecture, you need to update it for Integrity and then compile it on native Integrity.

Software sensitive to the new 32-bit object file format

The HP-UX object file format for Integrity is based on ELF. ELF (Executable Linking Format) is an industry-standard object file format.

The current 64-bit version of HP-UX 11.x on PA uses the ELF-64 object file format. ELF-64 is, for the most part, a simple extension of the ELF-32 format, as originally defined by AT&T Corporation.

For 32-bit object files on Integrity, HP-UX has changed from SOM object file format to ELF-32 object file format. The SOM (System Object Model) format is a 32-bit, HP-proprietary object file format for all releases of HP-UX on PA. Although moving to the ELF-32 object file format requires changes to software that manipulates object files, it is easier for you to maintain this software on multiple UNIX systems in the future.

Software sensitive to the new debug format

Finally, the format for debug information has changed for Integrity. The new format should be easier to work with, but the change affects debuggers and other software that read and write debug information. Therefore, such software cannot be pre-enabled for Integrity on HP-UX 11.x.