a.out man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

a.out(4)							      a.out(4)

NAME
       a.out - assembler and link editor output

SYNOPSIS
DESCRIPTION
   ELF a.out
       The  file  name	is  the default output file name from the link editor,
       ld(1).  The link editor will make an executable if there were no errors
       in  linking.  The output file of the assembler, as(1), also follows the
       format of the file although its default file name is different.

       Programs that manipulate ELF files may use  the	library	 that  elf(3E)
       describes.   An overview of the file format follows.  For more complete
       information, see the references given below.

			Linking View		      Execution View
		  _______________________	  _______________________
			  ELF header			 ELF header
		  |_____________________|	  |______________________|
		  |Program header table |	  |  Program header table|
		  |	  optional	|	  |			 |
		  |_____________________|	  | _____________________|
		  |	 Section 1	|	  |			 |
		  |_____________________|	  |			 |
		  |	   . . .	|	  |	  Segment 1	 |
		  |			|	  |			 |
		  |_____________________|	  | _____________________|
		  |	 Section n	|	  |			 |
		  |_____________________|	  |			 |
		  |	   . . .	|	  |	  Segment 2	 |
		  |			|	  |			 |
		  |_____________________|	  | _____________________|
		  |	   . . .	|	  |	    . . .	 |
		  |_____________________|	  | _____________________|
		  | Section header table|	  |  Section header table|
		  |			|	  |	   optional	 |
		  |_____________________|	  | _____________________|

       An ELF header resides  at  the  beginning  and  holds  a	 ``road	 map''
       describing  the	file's organization.  Sections hold the bulk of object
       file information for the linking view: instructions, data,  symbol  ta‐
       ble,  relocation information, and so on.	 Segments hold the object file
       information for the program execution view.  As shown,  a  segment  may
       contain one or more sections.

       A  program  header  table, if present, tells the system how to create a
       process image.  Files used to build a process image (execute a program)
       must have a program header table; relocatable files do not need one.  A
       section header table contains information describing  the  file's  sec‐
       tions.	Every  section	has  an	 entry	in the table; each entry gives
       information such as the section name, the  section  size,  and  so  on.
       Files  used  during  linking  must  have	 a section header table; other
       object files may or may not have one.

       Although the figure shows the program header  table  immediately	 after
       the  ELF	 header,  and the section header table following the sections,
       actual files may differ.	 Moreover, sections and segments have no spec‐
       ified order.  Only the ELF header has a fixed position in the file.

       When  an	 file  is loaded into memory for execution, three logical seg‐
       ments are set up: the text segment, the data segment (initialized  data
       followed by uninitialized, the latter actually being initialized to all
       0's), and a stack.  The text segment is not writable by the program; if
       other processes are executing the same file, the processes will share a
       single text segment.

       The data segment starts at the next maximal page boundary past the last
       text  address.	(If  the  system supports more than one page size, the
       ``maximal page'' is the largest	supported  size.)   When  the  process
       image  is created, the part of the file holding the end of text and the
       beginning of data may appear twice.  The duplicated chunk of text  that
       appears at the beginning of data is never executed; it is duplicated so
       that the operating system may bring in pieces of the file in  multiples
       of  the actual page size without having to realign the beginning of the
       data section to a page boundary.	 Therefore, the first data address  is
       the sum of the next maximal page boundary past the end of text plus the
       remainder of the last text address divided by the  maximal  page	 size.
       If  the	last  text  address is a multiple of the maximal page size, no
       duplication is necessary.   The	stack  is  automatically  extended  as
       required.  The data segment is extended as requested by the brk(2) sys‐
       tem call.

   SOM a.out (PA-RISC Only)
       The file name is the default file name for the  output  file  from  the
       assembler  (see	as(1)),	 compilers,  and  the linker (see ld(1)).  The
       assembler and compilers create  relocatable  object  files,  ready  for
       input  to  the  linker.	The linker creates executable object files and
       shared library files.

       An object file consists of a file header, auxiliary headers, space dic‐
       tionary,	 subspace  dictionary,	symbol	table, relocation information,
       compiler records, space string table, symbol string table, and the data
       for  initialized code and data.	Not all of these sections are required
       for all object files.  The file must begin with the  file  header,  but
       the  remaining  sections do not have to be in any particular order; the
       file header contains pointers to each of	 the  other  sections  of  the
       file.

       A  relocatable  object file, created by the assembler or compiler, must
       contain at least the following sections: file header, space dictionary,
       subspace dictionary, symbol table, relocation information, space string
       table, symbol string table, and code and data.	It  may	 also  contain
       auxiliary  headers  and	compiler records.  Relocatable files generally
       contain unresolved symbols.  The linker combines relocatable files  and
       searches	 libraries to produce an executable file.  The linker can also
       be used to combine relocatable files and produce a new relocatable file
       as output, suitable for input to a subsequent linker run.

       An  executable file, created by the linker, typically contains the fol‐
       lowing sections: file header, an HP-UX auxiliary header, space  dictio‐
       nary,  subspace	dictionary,  symbol  table, space string table, symbol
       string table, and code and data.	 The linker also copies any  auxiliary
       headers	and  compiler records from the input files to the output file.
       If the file has been stripped (see strip(1)), it	 will  not  contain  a
       symbol  table, symbol string table, or compiler records.	 An executable
       file must not contain any unresolved symbols.

       A shared library file, created by the linker, contains  the  same  sec‐
       tions found in an executable file, with additional information added to
       the code section of the file.  This additional information  contains  a
       header,	export	table, import table, and dynamic relocation records to
       be used by the dynamic loader.

       Programs consist of two loadable spaces: a shared,  non-writable,  code
       space  named  and  a  private, writable, data space named A program may
       contain another loadable, private space named  A	 program  may  contain
       other  unloadable spaces that contain data needed by development tools.
       For example, symbolic debugging information is  contained  in  a	 space
       named  or  The linker treats loadable and unloadable spaces exactly the
       same, so the full generality of symbol  resolution  and	relocation  is
       available for the symbolic debugging information.

       Spaces  have  an	 addressing range of 4,294,967,296 (2^32) bytes.  Each
       loadable space is divided into four  1,073,741,824  (2^30)  byte	 quad‐
       rants.	The  HP-UX operating system places all code in the first quad‐
       rant of the space, all data in the second quadrant of  the  space,  and
       all shared library code in the third quadrant of shared memory space.

       Each  space  is also divided into logical units called subspaces.  When
       the linker combines relocatable object files, it groups	all  subspaces
       from the input files by name, then arranges the groups within the space
       by a sort key associated with each subspace.  Subspaces are not	archi‐
       tecturally  significant;	 they merely provide a mechanism for combining
       individual parts of spaces independently from many input	 files.	  Some
       typical subspaces in a program are shown in the following table:

		$SHLIB_INFO$   Information needed for dynamic loading
		$MILLICODE$    Code for millicode routines
		$LIT$	       Sharable literals
		$CODE$	       Code
		$UNWIND$       Stack unwind information
		$GLOBAL$       Outer block declarations for Pascal
		$DATA$	       Static initialized data
		$COMMON$       FORTRAN common
		$BSS$	       Uninitialized data
		$TBSS$	       Thread local storage

       Subspaces can be initialized or uninitialized (although typically, only
       and are uninitialized).	The subspace dictionary entry for an  initial‐
       ized subspace contains a file pointer to the initialization data, while
       the entry for an uninitialized subspace contains only a 32-bit  pattern
       used to initialize the entire area at load time.

       In  a  relocatable file, initialized code and data often contain refer‐
       ences to locations elsewhere in the file,  and  to  unresolved  symbols
       defined	in  other  files.   These  references are patched at link time
       using the relocation information.  Each entry in the relocation	infor‐
       mation (a "fixup") specifies a location within the initialized data for
       a subspace, and an expression that defines the actual value that should
       be placed at that location, relative to one or two symbols.

       The  linker  summarizes	the subspace dictionary in the HP-UX auxiliary
       header when creating an executable file.	 HP-UX programs	 contain  only
       three  separate	sections:  one for the code, one for initialized data,
       and one for uninitialized data.	By convention, this  auxiliary	header
       is placed immediately following the file header.

       When an file is loaded into memory for execution, three areas of memory
       are set up: the code is loaded  into  the  first	 quadrant  of  a  new,
       sharable	 space;	 the  data  (initialized followed by uninitialized) is
       loaded into the second quadrant of a new, private space; and a stack is
       created	beginning  at  a  fixed	 address near the middle of the second
       quadrant of the data space.

       If the file uses shared libraries, then the dynamic  loader  is	loaded
       into  memory  and  called  to  map  into	 memory	 all  shared libraries
       requested by the program.  The shared library text is loaded  into  the
       third  quadrant of the shared memory space, and the shared library data
       is allocated in the second quadrant of the data space.

       The file format described here is a common  format  for	all  operating
       systems designed for HP's Precision Architecture.  Therefore, there are
       some fields and structures that are not used  on	 HP-UX	or  have  been
       reserved for future use.

   File Header
       The  format  of the file header is described by the following structure
       declaration from

       The timestamp is a two-word structure as shown below.  If unused,  both
       fields are zero.

   Auxiliary Headers
       The  auxiliary headers are contained in a single contiguous area in the
       file, and are located by a pointer in the file header.  Auxiliary head‐
       ers  are	 used for two purposes: to attach users' version and copyright
       strings to an object file, and to contain  the  information  needed  to
       load an executable program.  In an executable program, the HP-UX auxil‐
       iary header must precede all other auxiliary  headers.	The  following
       declarations are found in

   Space Dictionary
       The  space  dictionary  consists	 of  a	sequence  of space records, as
       defined in

       The strings for the space names are contained in the space strings  ta‐
       ble,  which  is located by a pointer in the file header.	 Each entry in
       the space strings table is preceded by a 4-byte	integer	 that  defines
       the length of the string, and is terminated by one to five null charac‐
       ters to pad the string out to a word boundary.  Indices to  this	 table
       are  relative to the start of the table, and point to the first byte of
       the string (not the preceding length word).  The union defined below is
       used for all such string pointers; the character pointer is defined for
       programs that read the string table into memory and  wish  to  relocate
       in-memory copies of space records.

   Subspace Dictionary
       The  subspace dictionary consists of a sequence of subspace records, as
       defined in Strings for  subspace	 names	are  contained	in  the	 space
       strings table.

   Symbol Table
       The  symbol  table  consists  of a sequence of entries described by the
       structure shown below, from Strings for symbol and qualifier names  are
       contained  in  the  symbol  strings table, whose structure is identical
       with the space strings table.

       The meaning of the symbol value depends on the symbol  type.   For  the
       code  symbols (generic code, program entry points, procedure and milli‐
       code entry points), the low-order two bits of the symbol	 value	encode
       the  execution privilege level, which is not used on HP-UX, but is gen‐
       erally set to 3.	 The symbol value with those bits masked  out  is  the
       address of the symbol (which is always a multiple of 4).	 For data sym‐
       bols, the symbol value is simply the address of the symbol.  For thread
       local  storage  symbols	(not  commons), the symbol value is the thread
       local storage offset in a library or executable file, and is  the  size
       of  the	symbol	if in a relocatable object file.  For storage requests
       and thread local storage commons, the symbol value  is  the  number  of
       bytes requested; the linker allocates space for the largest request for
       each symbol in the or subspaces, unless a local or universal symbol  is
       found  for  that	 symbol	 (in which case the storage request is treated
       like an unsatisfied reference).

       If a relocatable file is compiled with parameter type checking,	exten‐
       sion  records  follow symbols that define and reference procedure entry
       points and global variables.  The first extension record,  the  defines
       the type of the return value or global variable, and (if a procedure or
       function) the number of parameters and the types	 of  the  first	 three
       parameters.  If more parameter type descriptors are needed, one or more
       follow, each containing four more descriptors.	A  check  level	 of  0
       specifies no type checking; no extension records follow.	 A check level
       of 1 or more specifies checking of the return value or global  variable
       type.   A  check level of 2 or more specifies checking of the number of
       parameters, and a check level of 3 specifies checking the types of each
       individual  parameter.  The linker performs the requested level of type
       checking between unsatisfied symbols and local or universal symbols  as
       it resolves symbol references.

       The field in indicates the minimum alignment of the data, where a value
       of represents byte alignment.  The values for the and  (when  the  data
       type is not hashed) fields in are given in the following table.

	     Value   mode	       structure       arg_type
	     ────────────────────────────────────────────────────────────
	       0     any	       any	       any
	       1     value parm	       scalar	       void
	       2     reference parm    array	       signed byte
	       3     value-result      struct	       unsigned byte
	       4     name	       pointer	       signed short
	       5     variable	       long ptr	       unsigned short
	       6     function return   C string	       signed long
	       7     procedure	       Pascal string   unsigned long
	       8     long ref parm     procedure       signed dbl word
	       9		       function	       unsigned dbl word
	      10		       label	       short real
	      11				       real
	      12				       long real
	      13				       short complex
	      14				       complex
	      15				       long complex
	      16				       packed decimal
	      17				       struct/array

       For  procedure  entry  points, the parameter relocation bits define the
       locations of the formal parameters and the return value.	 Normally, the
       first  four words of the parameter list are passed in general registers
       instead of on the stack, and the return value is returned in  Floating-
       point  parameters  in  this  range are passed instead in floating-point
       registers and a floating-point value is returned in The parameter relo‐
       cation  bits consist of five pairs of bits that describe the first four
       words of the parameter list and the return value.  The leftmost pair of
       bits describes the first parameter word, and the rightmost pair of bits
       describes the return value.  The meanings of these bits	are  shown  in
       the following table.
		  │
	     Bits │ Meaning
	     ─────┼──────────────────────────────────────────────────────
	      00  │ No parameter or return value
	      01  │ Parameter or return value in general register
	      10  │ Parameter or return value in floating-point register
	      11  │ Double-precision floating-point value

       For double-precision floating-point parameters, the odd-numbered param‐
       eter word should be marked and the even-numbered parameter word	should
       be marked Double-precision return values are simply marked

       Every procedure call is tagged with a similar set of bits (see "Reloca‐
       tion Information" below), so that the linker can match each  call  with
       the  expectations  of the procedure entry point.	 If the call and entry
       point mismatch, the linker creates a stub that relocates the parameters
       and return value as appropriate.

   Relocation Information
       Each  initialized  subspace defines a range of fixups that apply to the
       data in that subspace.  A fixup request is associated with  every  word
       that requires relocation or that contains a reference to an unsatisfied
       symbol.	In relocatable object files created prior to HP-UX Release 3.0
       on  Series  800	systems,  each	fixup request is a five-word structure
       describing a code or data word to be  patched  at  link	time.	Object
       files  created  on  Release  3.0 or later contain variable-length fixup
       requests that describe every byte  of  the  subspace.   The  version_id
       field  in the file header distinguishes these two formats; the constant
       is found in older object files, and the	constant  is  found  in	 newer
       ones.

       In older object files, fixups can compute an expression involving zero,
       one, or two symbols and a constant, then extract a field of  bits  from
       that  result and deposit those bits in any of several different formats
       (corresponding to the Precision	Architecture  instruction  set).   The
       fixup_request_index field in the subspace dictionary entry indexes into
       the  fixup  request  area  defined  by  the   file   header   and   the
       fixup_request_quantity  field  refers  to  the number of fixup requests
       used for that subspace.	The structure of a fixup request is  contained
       in

       In newer object files, relocation entries consist of a stream of bytes.
       The fixup_request_index field in the subspace  dictionary  entry	 is  a
       byte  offset  into the fixup dictionary defined by the file header, and
       the fixup_request_quantity  field  defines  the	length	of  the	 fixup
       request	stream,	 in  bytes, for that subspace.	The first byte of each
       fixup request (the opcode) identifies the request  and  determines  the
       length of the request.

       In  general,  the  fixup stream is a series of linker instructions that
       governs how the linker places data in the file.	Certain fixup requests
       cause  the  linker to copy one or more bytes from the input subspace to
       the output subspace without change, while others direct the  linker  to
       relocate words or resolve external references.  Still others direct the
       linker to insert zeroes in the output subspace or to leave areas unini‐
       tialized	 without  copying any data from the input subspace, and others
       describe points in the code without contributing any new	 data  to  the
       output file.

       The  include  file defines constants for each major opcode.  Many fixup
       requests use a range of opcodes; only a constant for the	 beginning  of
       the  range  is defined.	The meaning of each fixup request is described
       below.  The opcode ranges and parameters for each fixup	are  described
       in the table further below.  Copy L bytes with no relocation.

       Insert L zero bytes into the output subspace.

       Skip L bytes in the output subspace.

       Copy one data word with relocation.
	      The  word is assumed to contain a 32-bit pointer relative to its
	      own subspace.

       Copy one data word with relocation relative to an external symbol
	      whose symbol index is S.

       Copy one data word as a 32-bit procedure label, referring to the symbol
       S.
	      The  original  contents of the word should be 0 (no static link)
	      or 2 (static link required).

       Copy one data word as a space reference.
	      This fixup request is not currently supported.

       Copy L bytes from the input subspace,
	      replicating the data to fill M bytes in the output subspace.

       Copy one instruction word with relocation.
	      The word is assumed to be a pc-relative procedure call  instruc‐
	      tion  (for example, The target procedure is identified by symbol
	      S, and the parameter relocation bits are R.

       Copy one instruction word with relocation.
	      The word is assumed to be an absolute procedure call instruction
	      (for  example,  The  target procedure is identified by symbol S,
	      and the parameter relocation bits are R.

       Copy one instruction word with relocation.
	      The word is assumed to be a dp-relative load or  store  instruc‐
	      tion  (for example, The target symbol is identified by symbol S.
	      The linker forms the difference between the value of the	symbol
	      S	 and  the  value  of the symbol By convention, the value of is
	      always contained in register 27.	Instructions may have a	 small
	      constant in the displacement field of the instruction.

       Copy one instruction word with relocation.
	      The  word	 is assumed to be a register-18-relative load or store
	      instruction (for example, The target  symbol  is	identified  by
	      symbol  S.   The linker computes a linkage table offset relative
	      to register 18 (reserved for a linkage table  pointer  in	 posi‐
	      tion-independent code) for the symbol S.

       Copy one instruction word with relocation.
	      The  word	 is assumed to be an instruction referring to symbol S
	      (for example, Instructions may have a small constant in the dis‐
	      placement field of the instruction.

       Copy one instruction word with relocation.
	      The  word	 is  assumed  to be a short millicode call instruction
	      (for example, The linker forms the difference between the	 value
	      of the target symbol S and the value of symbol 1 in the module's
	      symbol table.  By convention, the value of symbol 1 should  have
	      been  previously	loaded	into the base register used in the BLE
	      instruction.  The instruction may have a small constant  in  the
	      displacement field of the instruction.

       Copy one instruction word with relocation.
	      The word is assumed to be part of a code sequence forming a pro‐
	      cedure label (for example, referring to symbol S.	 The  instruc‐
	      tion  should  contain  the value 0 (no static link) or 2 (static
	      link required) in its displacement field.

       Copy one instruction word conditionally.
	      On HP-UX, the linker always replaces the word  with  a  instruc‐
	      tion.

       Define a procedure entry point.
	      The stack unwind bits, U, and the frame size, F, are recorded in
	      a stack unwind descriptor.

       Define an alternate procedure entry point.

       Define a procedure exit point.

       Define the beginning of a try/recover region.

       Define the end of a try/recover region.
	      The offset R defines the distance in bytes from the end  of  the
	      region to the beginning of the recover block.

       Define the beginning of a branch table.

       Define the end of a branch table.

       Define an auxiliary unwind table.
	      is a symbol index of the symbol that labels the beginning of the
	      compilation unit string table.  is the offset, relative  to  the
	      symbol,  of the scope name string.  is an integer specifying the
	      scope kind.

       Define the beginning of statement number N.

       Define the beginning of a secondary statement number N.

       Pop one word from the expression stack
	      and copy one data word from the input  subspace  to  the	output
	      subspace, adding the popped value to it.

       Pop one word from the expression stack,
	      and  copy	 one  instruction  word from the input subspace to the
	      output subspace, adding the popped  value	 to  the  displacement
	      field of the instruction.

       Use an F′ field selector for the next fixup request instead of
	      the default appropriate for the instruction.

       Use an L-class field selector for the next fixup request instead of
	      the  default  appropriate for the instruction.  Depending on the
	      current rounding mode, L′, LS′, LD′, or LR′ may be used.

       Use an R-class field selector for the next fixup request instead of
	      the default appropriate for the instruction.  Depending  on  the
	      current rounding mode, R′, RS′, RD′, or RR′ may be used.

       Select round-down mode (L′/R′).
	      This  is	the  default  mode  at the beginning of each subspace.
	      This setting remains in effect until explicitly changed or until
	      the end of the subspace.

       Select round-to-nearest-page mode (LS′/RS′).
	      This setting remains in effect until explicitly changed or until
	      the end of the subspace.

       Select round-up mode (LD′/RD′).
	      This setting remains in effect until explicitly changed or until
	      the end of the subspace.

       Select round-down-with-adjusted-constant mode (LR′/RR′).
	      This setting remains in effect until explicitly changed or until
	      the end of the subspace.

       Use the constant V for the next fixup request in place of the constant
	      from the data word or instruction in the input subspace.

       Toggle "translated" mode.
	      This fixup request is generated only  by	the  linker  during  a
	      relocatable link to indicate a subspace that was originally read
	      from an old-format relocatable object file.

       Stack operations.
	      The second byte of  this	fixup  request	contains  a  secondary
	      opcode.	In  the descriptions below, A refers to the top of the
	      stack and B refers to the next item on the stack.	 All items  on
	      the stack are considered signed 32-bit integers.
	      Push the (positive) constant V.
	      Push the current virtual address.
	      Pop A and B, then push max(A, B).
	      Pop A and B, then push min(A, B).
	      Pop A and B, then push A + B.
	      Pop A and B, then push B − A.
	      Pop A and B, then push A * B.
	      Pop A and B, then push B / A.
	      Pop A and B, then push B % A.
	      Pop A and B, then push A & B.
	      Pop A and B, then push A | B.
	      Pop A and B, then push A XOR B.
	      Replace A with its complement.
	      If C = 0, pop A and B, then push B << A.
		     Otherwise, replace A with A << C.
	      If C = 0, pop A and B, then push B >> A.
		     Otherwise,	 replace  A with A >> C.  The shifting is done
		     with sign extension.
	      If C = 0, pop A and B, then push B >> A.
		     Otherwise, replace A with A >> C.	The shifting  is  done
		     with zero fill.
	      Push the (negative) constant V.

       More stack operations.
	      Push the (positive) constant V.
	      Push the value of the symbol S.
	      Push the value of a procedure label for symbol S.
		     The static link bit is L.
	      Push the (negative) constant V.

       More stack operations.
	      Push  the	 value	of the procedure entry point S.	 The parameter
	      relocation bits are R.
	      Push the constant V.

       The linker keeps a queue of  the	 last  four  unique  multi-byte	 fixup
       requests.
	      This  is an abbreviation for a fixup request identical to one on
	      the queue.  The queue index X references one of the four; X =  0
	      refers  to  the  most  recent.   As  a side effect of this fixup
	      request, the referenced fixup is	moved  to  the	front  of  the
	      queue.

       Indicates that the following fixup is applied to the first
	      of a three-instruction sequence to access data, generated by the
	      compilers to enable the importing of shared library data.

       Uses a (N′) field selector for the next fixup request.
	      This indicates that zero bits are to be used for	the  displace‐
	      ment  on the instruction.	 This fixup is used to identify three-
	      instruction sequences  to	 access	 data  (for  importing	shared
	      library data).

       Defines the beginning of a line table.
	      CU  is a symbol index of the symbol that labels the beginning of
	      the line table.  SM is the offset relative to the CU symbol.  ES
	      designates the version information for the current line table.

       Defines an escape entry to be entered into the line table.
	      ES  designates  the escape entry entered in the table.  M desig‐
	      nates the number of R_STATEMENT fixups to be interpreted as  raw
	      8-bit table data.

       Override the following fixup,
	      which  is	 expected  to be a R_DATA_ONE_SYMBOL fixup to copy one
	      data word without relocation when	 building  a  shared  library.
	      The  absolute  byte offset of the symbol relative to the linkage
	      table pointer is copied.	If the linker is building  a  complete
	      executable, the absolute virtual address is copied.

       Fixup used to pass comment information from the compiler
	      to  the  linker.	 This  fixup has a 5 byte argument that can be
	      skipped and ignored by applications.

       Override the next one of these fixups seen:
	      R_DP_RELATIVE,  R_DLT_REL,  or  R_DATA_ONE_SYMBOL,  to  use  the
	      thread  local  storage offset when fixing the instruction.  This
	      fixup is also used to catch thread  local	 storage  symbol  mis‐
	      matches.

       Fixups in this range are reserved for internal use by the compilers and
       linker.

       The following table shows the mnemonic fixup request  type  and	length
       and parameter information for each range of opcodes.  In the parameters
       column, the symbol D refers to the difference between  the  opcode  and
       the  beginning  of the range described by that table entry; the symbols
       B1, B2, B3, and B4 refer to the value of the next one, two,  three,  or
       four bytes of the fixup request, respectively.

     Mnemonic		 Opcodes   Length   Parameters
     ─────────────────────────────────────────────────────────────────────────────
     R_NO_RELOCATION	   0-23	      1	    L = (D+1) * 4
			  24-27	      2	    L = (D<<8 + B1 + 1) * 4
			  28-30	      3	    L = (D<<16 + B2 + 1) * 4
			   31	      4	    L = B3 + 1
     R_ZEROES		   32	      2	    L = (B1 + 1) * 4
			   33	      4	    L = B3 + 1
     R_UNINIT		   34	      2	    L = (B1 + 1) * 4
			   35	      4	    L = B3 + 1
     R_RELOCATION	   36	      1	    none
     R_DATA_ONE_SYMBOL	   37	      2	    S = B1
			   38	      4	    S = B3
     R_DATA_PLABEL	   39	      2	    S = B1
			   40	      4	    S = B3

     R_SPACE_REF	   41	      1	    none
     R_REPEATED_INIT	   42	      2	    L = 4; M = (B1 + 1) * 4
			   43	      3	    L = (B1 + 1) * 4; M = (B1 + 1) * L
			   44	      5	    L = (B1 + 1) * 4; M = (B3 + 1) * 4
			   45	      8	    L = B3 + 1; M = B4 + 1
     R_PCREL_CALL	  48-57	      2	    R = rbits1(D); S = B1
			  58-59	      3	    R = rbits2(D<<8 + B1); S = B1
			  60-61	      5	    R = rbits2(D<<8 + B1); S = B3
     R_ABS_CALL		  64-73	      2	    R = rbits1(D); S = B1
			  74-75	      3	    R = rbits2(D<<8 + B1); S = B1
			  76-77	      5	    R = rbits2(D<<8 + B1); S = B3
     R_DP_RELATIVE	  80-111      1	    S = D
			   112	      2	    S = B1
			   113	      4	    S = B3
     R_DLT_REL		   120	      2	    S = B1
			   121	      4	    S = B3
     R_CODE_ONE_SYMBOL	 128-159      1	    S = D
			   160	      2	    S = B1
			   161	      4	    S = B3
     R_MILLI_REL	   174	      2	    S = B1
			   175	      4	    S = B3
     R_CODE_PLABEL	   176	      2	    S = B1
			   177	      4	    S = B3
     R_BREAKPOINT	   178	      1	    none
     R_ENTRY		   179	      9	    U,F = B8 (U is 37 bits; F is 27 bits)
			   180	      6	    U = B5 >> 3; F = pop A
     R_ALT_ENTRY	   181	      1	    none
     R_EXIT		   182	      1	    none
     R_BEGIN_TRY	   183	      1	    none
     R_END_TRY		   184	      1	    R = 0
			   185	      2	    R = sign_extend(B1) * 4
			   186	      4	    R = sign_extend(B3) * 4
     R_BEGIN_BRTAB	   187	      1	    none
     R_END_BRTAB	   188	      1	    none
     R_STATEMENT	   189	      2	    N = B1
			   190	      3	    N = B2
			   191	      4	    N = B3
     R_DATA_EXPR	   192	      1	    none
     R_CODE_EXPR	   193	      1	    none
     R_FSEL		   194	      1	    none
     R_LSEL		   195	      1	    none
     R_RSEL		   196	      1	    none
     R_N_MODE		   197	      1	    none
     R_S_MODE		   198	      1	    none
     R_D_MODE		   199	      1	    none
     R_R_MODE		   200	      1	    none
     R_DATA_OVERRIDE	   201	      1	    V = 0
			   202	      2	    V = sign_extend(B1)
			   203	      3	    V = sign_extend(B2)
			   204	      4	    V = sign_extend(B3)
			   205	      5	    V = B4
     R_TRANSLATED	   206	      1	    none
     R_AUX_UNWIND	   207	     12	    CU,SN,SK = B11 (CU is 24 bits;
					    SN is 32 bits; SK is 32 bits)
     R_COMP1		   208	      2	    OP = B1; V = OP & 0x3f; C = OP & 0x1f
     R_COMP2		   209	      5	    OP = B1; S = B3; L = OP & 1;
					    V = ((OP & 0x7f) << 24) | S
     R_COMP3		   210	      6	    OP = B1; V = B4;
					    R = ((OP & 1) << 8) | (V >> 16);
					    S = V & 0xffffff
     R_PREV_FIXUP	 211-214      1	    X = D
     R_N0SEL		   216	      1	    none
     R_N1SEL		   217	      1	    none
     R_SEC_STMT		   215	      1	    none
     R_LINETAB		   218	      9	    ES = B1; CU = B3; SM = B4
     R_LINETAB_ESC	   219	      3	    ES = B1; M = B1
     R_LTP_OVERRIDE	   220	      1	    none
     R_COMMENT		   221	      6	    OP = B1; V = B2 to B6
     R_TP_OVERRIDE	   222	      1	    none
     R_RESERVED		 224-255	    reserved

       Parameter  relocation  bits  are	 encoded  in the fixup requests in two
       ways, noted as rbits1 and rbits2 in the above table.

       The first encoding recognizes that the most common procedure calls have
       only  general  register	arguments with no holes in the parameter list.
       The encoding for such calls is simply the number of parameters in  gen‐
       eral registers (0 to 4), plus 5 if there is a return value in a general
       register.

       The second encoding is more complex.  The 10 argument  relocation  bits
       are compressed into 9 bits by eliminating some impossible combinations.
       The encoding is the combination of three contributions.	The first con‐
       tribution is the pair of bits for the return value, which are not modi‐
       fied.  The second contribution is 9 if the first	 two  parameter	 words
       together	 form  a  double-precision parameter; otherwise, it is 3 times
       the pair of bits for the first word plus the pair of bits for the  sec‐
       ond  word.   Similarly,	the  third contribution is formed based on the
       third and fourth parameter words.  The second  contribution  is	multi‐
       plied  by  40,  the  third is multiplied by 4, then the three are added
       together.

   Compiler Records
       Compiler records are placed in relocatable files by  each  compiler  or
       assembler to identify the version of the compiler that was used to pro‐
       duce the file.  These records are copied into the  executable  file  by
       the  linker, but are strippable.	 The structure of a compiler record is
       shown below.  All strings are contained in the symbol string table.

       The format of the compilation record  is	 described  by	the  following
       structure declaration from

FILES
SEE ALSO
   System Tools
       as(1)	 Translate assembly code to machine code
       cc(1)	 Invoke the HP-UX C compiler
       ld(1)	 Invoke the link editor

   Miscellaneous
       crt0(3)	 Execution startup routine
       elf(3E)	 For the ELF a.out only
       end(3C)	 Symbol of the last locations in program
       magic(4)	 Magic number for HP-UX implementations
       nm(1)	 Print name list of object file
       strip(1)	 Strip symbol and line number information from an object file

								      a.out(4)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net