Browse Prior Art Database

Method to Intercept Dynamically Loaded Subroutine Calls on the IBM RISC System/6000 AIX Operating System

IP.com Disclosure Number: IPCOM000107642D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 6 page(s) / 224K

Publishing Venue

IBM

Related People

Fuqua, TW: AUTHOR

Abstract

On the IBM RISC System/6000* (RS/6000) AIX* operating system, object modules (.o files) may be created as dynamically loaded, shared object modules. Each module may export zero or more subroutine definitions for use by executable programs. The shared object module is not loaded into an executable program until the program is actually invoked. At program execution, the operating system scans a list of directories defined by the system and by the user (LIBPATH), searches for the shared object module, loads the module, links the module into the program, and begins program execution.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 31% of the total text.

Method to Intercept Dynamically Loaded Subroutine Calls on the IBM RISC System/6000 AIX Operating System

       On the IBM RISC System/6000* (RS/6000) AIX* operating
system, object modules (.o files) may be created as dynamically
loaded, shared object modules.  Each module may export zero or more
subroutine definitions for use by executable programs.  The shared
object module is not loaded into an executable program until the
program is actually invoked.  At program execution, the operating
system scans a list of directories defined by the system and by the
user (LIBPATH), searches for the shared object module, loads the
module, links the module into the program, and begins program
execution.

      It is standard practice to change LIBPATH such that the shared
object module found and loaded at runtime is different than the
module found and used at program creation (compilation and linkage)
time.  This enables code library upgrades and bug fixes by replacing
dynamic modules without requiring dependent application programs be
rebuilt.

      A new method is presented to intercept subroutine calls made by
the application program on the shared object module target.  Such a
mechanism is useful for application testing, application performance
measurement and other purposes.  All subroutine calls made by a
particular application program on the target shared object module
pass through an 'interceptor' module, enabling program
instrumentation for testing, measurement and other purposes.  The
interceptor module may, at its discretion, pass the application's
request on to the original target module, or it may modify the
request.  The interceptor module is not a part of the application
being tested, or of the target shared object module providing
services to the application.

      A shared object module provides a list of exported services or
symbols to application programs. Application programs using the
symbols of a shared object module contain references to the symbol
and the AIX pathname of the shared object module providing the symbol
rather than the object module itself. Under most circumstances, the
module pathname is a relative, rather than absolute, pathname.

      At program execution time, the AIX loader uses the pathname
associated with the symbol to locate the shared object module where
the symbol is defined.  When the module's pathname is relative, the
LIBPATH environment variable is used to specify a list of zero or
more directories to use as the root of the relative pathname. The
first instance of the shared object module found by scanning the
library list is loaded into the application program's process storage
and linked into the application's namespace.

                            (Image Omitted)

      Any previously existing method to intercept or tap at the
boundary between the application and the target module is not known.

      The new method is to intercept su...