Aries(5)

NAME

Aries — emulate PA-RISC applications on Itanium-based processor family

DESCRIPTION

Aries is a binary emulator that transparently emulates 32-bit and 64-bit HP-UX PA-RISC applications on HP-UX Itanium-based machines. Aries is transparent in that:

The HP-UX PA-RISC application is not re-compiled.
The user does not explicitly invoke Aries.

The HP-UX Itanium-based kernel recognizes a HP-UX PA-RISC executable and invokes Aries to emulate the application.

Aries consists of 4 shared libraries :

/usr/lib/hpux32/aries32.so
/usr/lib/hpux32/pa_boot32.so
/usr/lib/hpux64/aries64.so
/usr/lib/hpux64/pa_boot64.so

aries32.so is the shared library that contains the Aries emulator for 32-bit applications. pa_boot32.so contains code to load aries32.so. Likewise, aries64.so is the emulator for 64-bit applications. pa_boot64.so loads aries64.so. Upon detecting a 32-bit HP-UX PA-RISC executable, the HP-UX Itanium-based kernel invokes pa_boot32.so, which loads aries32.so into memory and sets it up to emulate the HP-UX PA-RISC executable. Likewise, aries64.so is loaded for a 64-bit HP-UX PA-RISC executable.

PA GDB Support

Aries supports debugging of PA applications on HP-UX Itanium-based systems, using PA gdb.

On HP-UX Itanium-based systems /usr/ccs/bin contains the PA gdb32 and gdb64 binaries. A symbolic link named /usr/ccs/bin/gdbpa points to /usr/ccs/bin/gdb32. The HP-UX Itanium-based systems gdb recognizes the binary being debugged as a PA binary and launches /usr/ccs/bin/gdbpa under Aries.

Debugging PA Applications on Itanium-based Systems

The following steps have to be followed by the user in order to debug PA applications on HP-UX Itanium-based systems using PA gdb.

1.

Set the environment variable PA_DEBUG to 1.

2.

Set the environment variable SHELL to point to a PA shell, which should be present on the Itanium-based machine on which debugging is being carried out. PA shell can be obtained from a HP-UX PA-RISC machine from /usr/bin.

3.

Add /usr/ccs/bin to the PATH environment variable.

4.

Run gdb as:

$ gdb PA_binary

The rest of the debugging process is exactly similar to that followed on the HP-UX PA-RISC platform. All commands of gdb are supported subject to limitations listed under Limitations of PA GDB Support.

After debugging is finished, perform the following steps.

1.: Unset the environment variable PA_DEBUG.
2.: Restore the original value of the SHELL environment variable.

Limitations of PA GDB Support

The following are current limitations of PA gdb support.

1.: No support for debuggers other than HP-UX PA-RISC gdb for debugging an emulated PA program on Itanium-based systems.
2.: No support for attaching the debugger to a running emulated PA program on Itanium-based system.
3.: No support for conditional reporting of system call entry and exit events.
4.: No support for old gdb versions (of HP-UX 10.20 and earlier). However, debugging HP-UX 10.20 applications using a HP-UX 11.0 PA gdb is supported.
5.: PA gdb behaves differently for child programs created using fork() and vfork(). Since in Aries vfork() calls made by application are replaced by fork() calls, the exact behaviour shown by PA gdb on PA-RISC/HP-UX platform is not shown by the PA gdb running under Aries on HP-UX Itanium-based platform in this case.
6.: If the debugged program is hanging in a blocking system call, any attempt to get to the gdb command prompt by pressing ^C will not work. The process has to be killed from outside.

Generation of PA Core File

Aries supports creation of PA core file on Itanium-based system, when the emulated PA application dumps core.

The size of the core file is limited by ulimit() or setrlimit() values. See ulimit(2) and setrlimit(2).

The PA application core file generated by Aries will have the name as core.PA_application_name.

HP-UX PA-RISC debuggers are needed to analyze core files generated by Aries for PA applications. For instance, PA application core file generated by Aries can be debugged using /usr/ccs/bin/gdbpa on Itanium-based system. Alternately, the application's core file can be taken to a PA machine and debugged using a PA debugger, though it is a very tedious process and likely to be error-prone.

After Aries has successfully written core file for PA application, it will print the following message on stderr:

ARIES32/64: Core file for PA32/64 application 
saved to path/core.PA_application_name

If the emulated PA application results in a core file named just core or core.pid, it will be Aries core dump and not that of the emulated PA application.

Debugging Aries-Generated PA Core File on a Different Machine

Debugging Aries-generated PA core file on different machine (PA or Itanium) can be done only with PA wdb-3.0.01 or later.

The following steps should be followed to debug Aries-generated PA core file on a machine other than the one on which the core file was generated.

1.

Transfer the core file and all the shared libraries used by the PA application from the Itanium-based machine where core dump file was generated to the target machine.

2.

Set the GDB_SHLIB_PATH environment variables to a colon-separated list of directory pathnames where the transferred shared libraries reside.

3.

Run gdb as:

$ gdb PA_application PA_core_file

Performance-Enhanced Dynamic Translator Beta

1. Introduction

Aries (32-bit - /usr/lib/hpux32/aries32.so) shipped with HP-UX 11i Version 2.0 is augmented with the beta version of a performance-enhanced dynamic translator. However this beta translator will NOT be turned ON by default. This means that the regular usage of Aries will not be affected at all. The 64-bit Aries, /usr/lib/hpux64/aries64.so, does not consist of this beta translator.

2. Usage

In order to turn on the beta translator, the following option string needs to be used in the .ariesrc file:

-fast_trans

Aries is supposed to run with default options. However, the resource file is a mechanism by which special options can be supplied to Aries. While starting up a PA application, Aries searches for .aries[64]rc file in the current directory, then in the user's home directory and then in the root (/) directory, in that order. If Aries fails to locate it in any of the three places it uses default options. In the context of the beta translator, -fast_trans is the special option that needs to be supplied via the .ariesrc file, so that Aries invokes the beta translator while emulating the given PA application. If no .ariesrc file is found by Aries, or, if .ariesrc file is found but -fast_trans is not found in that file, then Aries uses the old translator as the default.

3. Warning

Due to the beta-nature of this translator, the users need to be aware that an element of risk is involved in deploying the beta translator for mission-critical applications. However, we encourage that this new translator be used more and more in order for it to become more robust, so that it soon attains the same levels of reliability as the existing translator.

4. Performance of beta translator

Based on the measurements performed until this release, the beta translator has been found, on an average, to be 20% faster than the existing translator, with regards to the translation time. However, how this improvement in the translation time reflects in the emulated application's overall performance is a variable factor. It has been observed in the lab that an overall performance gain of 20% on an average can be expected in applications that contain an average mix of compute-intensive and user-intensive actions. More precise performance measurements of the beta translator are being carried out.

Aries Supported Applications

Aries supports emulation of all HP-UX PA-RISC applications. This means, all the HP-UX Inter Process Communication mechanisms such as semaphores, shared memory, sockets, etc. are supported. The signal/exception behavior of a PA-RISC/HP-UX program is supported under Aries. All inter process communications between an emulated PA program and a native-running Itanium-based program is supported. There is only a very small subset of the PA-RISC application domain that is not supported under Aries. To ascertain whether a given application will run correctly under Aries or not, please determine if the application falls into one of the Aries limitations listed under section Aries Limitations.

Aries Limitations

Aries supports emulation of all HP-UX PA-RISC applications, with the following limitations/exceptions:

Aries does not support PA programs that load Itanium-based shared libraries. In other words, mixing PA binaries with Itanium-based shared libraries is not supported. Aries is meant only for pure PA binaries — that is, binaries that are either statically or dynamically linked with PA libraries only. However, any sort of inter process communication between a native Itanium-based program and an emulated PA program is supported.
The version of Aries that ships with HP-UX 11i Version 2.0 supports HP-UX PA-RISC applications that run on HP-UX 11i V1.6 and below. Aries does not support applications compiled on HP-UX version 8.x or earlier. However such applications should work fine if they run on a contemporary version of HP-UX (that is, HP-UX 11i V1.6 and earlier).
Aries does not support privileged PA-RISC instructions. Hence, device drivers and loadable kernel modules are not supported.
Aries does not guarantee correct emulation of PA applications which make assumptions about "time taken to execute certain pieces of application code and/or system calls". Such programs are theoretically un-synchronized programs and hence need to be corrected with proper synchronization techniques using mutexes, semaphores, etc. Such un-synchronized applications are found to be very rare in practice.
Aries does not support applications that use the ptrace() or profil() system calls. However, Aries supports debugging of emulated application using PA gdb. See section PA GDB Support for additional information on this. This limitation might affect debugger programs, which are normally not portable anyways.
Aries consumes a small amount of an application's virtual memory address space. Therefore Aries does not support applications that are nearly or completely maxed out on their virtual address space usage. Such applications, in practice, have been found to be extremely rare.
Aries supports both fork(), and vfork() system calls. However, Aries does not support applications that rely on differences between fork() and vfork(). However, most applications that use vfork() system call do use it with a purpose which is well known to the programmer. It is an extremely rare condition that a standard application would have any such reliance on the differences between fork() and vfork() calls. See vfork(2) and fork(2) for details.
When an emulated program makes any system call that returns the processor-related information, then under emulation Aries returns information pertinent to a PA-RISC 2.0 processor even as the emulated application runs on an Itanium-based machine. For instance, a call made to sysconf(2), with _SC_CPU_VERSION, will return CPU_PA_RISC2_0. This is an Aries policy that an emulated program sees a complete PA environment on Itanium-based system. If the application requires that it be able to determine that it is running on an Itanium-based machine then one method is for the application to use the system(3S) call and utilize the Itanium-based native command, getconf(1), to get the required fields. See system(3S), getconf(1) and sysconf(2) for more details.