


 a.out(4)	     Architecture-Dependent File Format		    a.out(4)




 NAME
      a.out - assembler and link editor output

 REMARKS
      A separate manual entry describes each implementation of the a.out
      file format for Series 300/400 and Series 700/800 systems.

 DESCRIPTION
      The a.out (i.e., object file) format is completely machine-dependent
      except for the first word, which contains a magic number as defined in
      magic(4).

      The archive symbol table format is also completely machine-dependent
      except for its name in the archive.  See ar(4) for a description of
      the format of the archive symbol table.

 SEE ALSO
      crt0(3), end(3C), a.out_300(4), a.out_800(4), ar(4), magic(4).




































 Hewlett-Packard Company	    - 1 -     HP-UX Release 9.0: August 1992






 a.out_300(4)		Series 300/400 Implementation		a.out_300(4)




 NAME
      a.out - assembler and link editor output

 Remarks:
      This manual entry describes the a.out file format for Series 300/400
      computers.  Refer to other a.out*(4) manual entries for descriptions
      of other implementations.

 DESCRIPTION
      The a.out file is the output file of the link editor ld (see ld(1).
      The linker makes a.out executable if there were no linking errors and
      no unresolved external references.  The assembler as (or ld with the
      -r option) produces non-executable files with the same basic
      structure.

      File a.out has eight defined sections: a header, the program text and
      data segments, a Pascal interface section, a symbol table, a
      supplementary symbol table, and text and data relocation information
      (in that order).	Pascal interface text will only be present in those
      Pascal code segments that have not been linked.  The symbol table may
      be missing if the program was linked with the ld -s option, or if the
      symbol table and debug information were removed by strip (see
      strip(1)).  The supplementary symbol table is present only in files
      containing position-independent code, or in files that were produced
      with the Pascal compiler or the +s option to the assembler.  Also note
      that relocation information is not normally present in executable
      files.

      In addition to these sections, there may be one or more extensions.
      Each extension is preceded by a header consisting of an extension-
      independent part and an extension-dependent part.	 Currently defined
      extensions include one for dynamic loading support and one for
      debugger support.	 The dynamic loader extension is actually placed
      within the text segment of shared library files (created with the -b
      option to ld) and executables that use shared libraries.	The debugger
      extension is placed after the relocation sections.  HP-UX compilers
      create this information under control of the -g option.

      When an a.out file is loaded into memory for execution, three logical
      segments 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 begins at location 0x0 in
      the core image; the header is not loaded.	 If the magic number (the
      first field in the header) is EXEC_MAGIC, it indicates that the text
      segment is not to be write-protected or shared, so the data segment
      will be contiguous with the text segment.	 If the magic number is
      SHARE_MAGIC or DEMAND_MAGIC, the data segment begins at the first 0
      mod 0x1000 byte boundary following the text segment, and the text
      segment is not writable by the program; if other processes are
      executing the same a.out file, they will share a single text segment.
      If the magic number is DEMAND_MAGIC, the text and data segments are



 Hewlett-Packard Company	    - 1 -     HP-UX Release 9.0: August 1992






 a.out_300(4)		Series 300/400 Implementation		a.out_300(4)




      not read in from the file until they are referenced by the program.

      The stack will occupy the highest possible locations in the core image
      and grow downward (the stack is automatically extended as required).
      The data segment is only extended as requested by the brk() system
      call (see brk(2)).

      Shared libraries, indicated by the magic number SHL_MAGIC, are similar
      to demand-loaded executables, except that they are loaded by the
      dynamic loader /lib/dld.sl (see dld.sl(5)) at some point during
      startup, rather than by exec(), and that the load address is
      arbitrary.  No stack segment is set up for shared libraries; they
      share the stack used by the executable.  The data and bss segments of
      a shared library are shared on a page by page basis by all processes
      using the library.  Whenever a process writes to a shared library data
      or bss segment, a modified copy of that page is made for the process.
      Dynamic load libraries, indicated by the magic number DL_MAGIC, are
      analagous to shared libraries except that the text segment is also
      made copy on write in order to support dynamic relocation.

      The start of the text segment in the a.out file is given by the macro
      TEXT_OFFSET(hdr), where hdr is a copy of the file header.	 The macro
      DATA_OFFSET(hdr) provides the starting location of the data segment.

      The value of a word in the text or data portions that is not a
      reference to an undefined external symbol is exactly the value that
      will appear in memory when the file is executed.	If a word in the
      text or data portion involves a reference to an undefined external
      symbol, as indicated by the relocation information (discussed below)
      for that word, then the value of the word as stored in the file is an
      offset from the associated external symbol.  When the file is
      processed by the link editor and the external symbol becomes defined,
      the value of the symbol will be added to the word in the file.

    Header
      The format of the a.out header for the MC68000 is as follows (segment
      sizes are in bytes):

	   struct exec {
	       MAGIC   a_magic;	       /* magic number */
	       short   a_stamp;	       /* version id */
	       short   a_highwater;    /* shlib highwater mark */
	       long    a_miscinfo;     /* miscellaneous info */
	       long    a_text;	       /* size of text segment */
	       long    a_data;	       /* size of data segment */
	       long    a_bss;	       /* size of bss segment */
	       long    a_trsize;       /* text relocation size */
	       long    a_drsize;       /* data relocation size */
	       long    a_pasint;       /* Pascal interface size */
	       long    a_lesyms;       /* symbol table size */
	       long    a_spared;



 Hewlett-Packard Company	    - 2 -     HP-UX Release 9.0: August 1992






 a.out_300(4)		Series 300/400 Implementation		a.out_300(4)




	       long    a_entry;	       /* entry point */
	       long    a_spares;
	       long    a_supsym;       /* supplementary symtab size */
	       long    a_drelocs;      /* nonpic relocations */
	       long    a_extension;    /* file offset of extension */
	   };

    Pascal Interface Section
      The Pascal interface section consists of the ASCII representation of
      the interface text for that Pascal module.

      The start of the Pascal interface section is given by the macro
      MODCAL_OFFSET(hdr).

    Symbol Table
      The symbol table consists of entries of the form:

	   struct nlist {
	       long	       n_value;
	       unsigned char   n_type;
	       unsigned char   n_length;
	       short	       n_almod;
	       int	       n_dlt:1;
	       int	       n_plt:1;
	       int	       n_dreloc:1;
	       int	       n_list:1;
	       int	       n_unused:12;
	   };

      This structure is followed by n_length ASCII characters which compose
      the symbol name.

      The n_type field indicates the type of the symbol; the following
      values are possible:

	   UNDEF     undefined symbol
	   ABS	     absolute symbol
	   TEXT	     text segment symbol
	   DATA	     data segment symbol
	   BSS	     bss segment symbol

      One of these values ORed with 040 indicates an external symbol.  One
      of these values ORed with 020 indicates an aligned symbol.  One of
      these values ORed with 0100 indicates a secondary definition.

      The bit fields are used by the linker for the relocation of position-
      independent code (generated with the +z option to the compilers) when
      creating a shared library.

      The start of the symbol table is given by the macro LESYM_OFFSET(hdr).




 Hewlett-Packard Company	    - 3 -     HP-UX Release 9.0: August 1992






 a.out_300(4)		Series 300/400 Implementation		a.out_300(4)




      In object files that were compiled as position-independent code,
      generated by the Pascal compiler, or assembled with the as +s option,
      a supplementary symbol table follows the standard symbol table.  This
      table is a simple array of eight-byte structures which stand in one-
      to-one correspondence with the symbol table entries.  The fields of
      this structure are used by the linker when creating a shared library.

    Relocation
      If relocation information is present, it amounts to eight bytes per
      relocatable datum.

      The format of the relocation data is:

	   struct r_info  {
	       long  r_address;
	       short  r_symbolnum;
	       char   r_segment;
	       char   r_length;
	   };

      The r_address field indicates the position of the relocation within
      the segment.

      The r_segment field indicates the segment referred to by the text or
      data word associated with the relocation word:

	   RTEXT     indicates the reference is to the text segment;
	   RDATA     indicates the reference is to initialized data;
	   RBSS	     indicates the reference is to bss (uninitialized data);
	   REXT	     indicates the reference is to an undefined external
		     symbol;
	   RPC	     indicates the reference is PC relative;
	   RDLT	     indicates the reference is to an offset from the base
		     of the data linkage table;
	   RPLT	     indicates the reference is to an entry within the
		     procedure linkage table.

      The latter three relocation types are found primarily in position-
      independent code.

      The r_symbolnum field contains a symbol number in the case of external
      references, and is unused otherwise.  The first symbol is numbered 0,
      the second 1, etc.

      The r_length field indicates the length of the datum to be relocated.

	   RBYTE     indicates it is a byte
	   RWORD     indicates it is a short
	   RLONG     indicates it is a long
	   RALIGN    indicates it is a special align symbol




 Hewlett-Packard Company	    - 4 -     HP-UX Release 9.0: August 1992






 a.out_300(4)		Series 300/400 Implementation		a.out_300(4)




      The start of the text relocation section is provided by the macro
      RTEXT_OFFSET(hdr).

      The start of the data relocation section is provided by the macro
      RDATA_OFFSET(hdr).

    Extensions
      The a_extension field of the header gives the file offset of the first
      extension, and each extension header gives the file offset of the
      next.  The dynamic loader extension, if present, will be the first
      extension present, and the debugger extension, if present, will be
      next.  Additional extensions can be defined by certain languages or
      tools.  When present, they are placed after the dynamic loader and
      debugger extensions.

      The extension header is of the form

	   struct header_extension
	   {
	       union
	       {
		   long spare1[13];
		   struct _dl_header dl_header;
		   struct _debug_header debug_header;
	       } e_spec;
	       short e_header;
	       short e_version;
	       long e_size;
	       long e_extension;
	   };

      The union allows for extension specific information to be included in
      the header.  The e_header field contains a constant which identifies
      the extension type.  Currently defined values include DL_HEADER and
      DEBUG_HEADER.  The e_version field can be used to identify different
      versions of an extension.	 The e_size field gives the collective size
      for the extension; e_extension gives the file offset of the next
      extension.

      For more information about the dynamic loader extension and the debug
      extension, consult the files /usr/include/shl.h and
      /usr/include/debug.h, respectively.

 SEE ALSO
      as_300(1), ld(1), nm_300(1), strip(1), crt0(3), end(3C), a.out_800(4),
      magic(4).








 Hewlett-Packard Company	    - 5 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




 NAME
      a.out - assembler and link editor output

 SYNOPSIS
      #include <a.out.h>

 Remarks:
      This manual entry describes the a.out file format for Series 700 and
      Series 800 computers.  Refer to other a.out(4) manual entries for
      descriptions of other valid implementations.

 DESCRIPTION
      The file name a.out is 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
      dictionary, 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
      following sections:  file header, an HP-UX auxiliary header, space
      dictionary, 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
      sections 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.



 Hewlett-Packard Company	    - 1 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      Programs for the Series 700/800 architecture consist of two loadable
      spaces: a shared, non-writable, code space named $TEXT$; and a
      private, writable, data space named $PRIVATE$.  A program may contain
      other non-loadable spaces that contain data needed by development
      tools; for example, symbolic debugging information is contained in a
      space named $DEBUG$.  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
      quadrants.  The HP-UX operating system places all code in the first
      quadrant of the $TEXT$ space, all data in the second quadrant of the
      $PRIVATE$ space, and all shared library code into 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
      architecturally 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
	   $SHLIB_DATA$	   Imported data from referenced shared libraries.
	   $BSS$	  Uninitialized data

      Subspaces can be initialized or uninitialized (although typically,
      only $BSS$ is uninitialized).  The subspace dictionary entry for an
      initialized 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 contains
      references 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
      information (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.





 Hewlett-Packard Company	    - 2 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      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 a.out file is loaded into memory for execution, three areas of
      memory are set up:  the a.out 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 a.out file uses shared libraries then the dynamic loader
      /lib/dld.sl is loaded into memory, and called to map all shared
      libraries, requested by the program, into memory.	 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 <filehdr.h>.

	   struct header {
	       short int system_id;		     /* system id */
	       short int a_magic;		     /* magic number */
	       unsigned int version_id;		     /* a.out format version */
	       struct sys_clock file_time;	     /* timestamp */
	       unsigned int entry_space;	     /* reserved */
	       unsigned int entry_subspace;	     /* reserved */
	       unsigned int entry_offset;	     /* reserved */
	       unsigned int aux_header_location;     /* file ptr to aux hdrs */
	       unsigned int aux_header_size;	     /* sizeof aux hdrs */
	       unsigned int som_length;		     /* length of object module */
	       unsigned int presumed_dp;	     /* reserved */
	       unsigned int space_location;	     /* file ptr to space dict */
	       unsigned int space_total;	     /* # of spaces */
	       unsigned int subspace_location;	     /* file ptr to subsp dict */
	       unsigned int subspace_total;	     /* # of subspaces */
	       unsigned int loader_fixup_location;   /* reserved */
	       unsigned int loader_fixup_total;	     /* reserved */
	       unsigned int space_strings_location;  /* file ptr to sp. strings */
	       unsigned int space_strings_size;	     /* sizeof sp. strings */
	       unsigned int init_array_location;     /* reserved */
	       unsigned int init_array_total;	     /* reserved */



 Hewlett-Packard Company	    - 3 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




	       unsigned int compiler_location;	     /* file ptr to comp recs */
	       unsigned int compiler_total;	     /* # of compiler recs */
	       unsigned int symbol_location;	     /* file ptr to sym table */
	       unsigned int symbol_total;	     /* # of symbols */
	       unsigned int fixup_request_location;  /* file ptr to fixups */
	       unsigned int fixup_request_total;     /* # of fixups */
	       unsigned int symbol_strings_location; /* file ptr to sym strings */
	       unsigned int symbol_strings_size;     /* sizeof sym strings */
	       unsigned int unloadable_sp_location;  /* file ptr to debug info */
	       unsigned int unloadable_sp_size;	     /* size of debug info */
	       unsigned int checksum;		     /* header checksum */
	   };

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

	   struct sys_clock {
	       unsigned int secs;
	       unsigned int nanosecs;
	   };

    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
      headers are used for two purposes:  users can attach version and
      copyright strings to an object file, and an auxiliary header contains
      the information needed to load an executable program.  In an
      executable program, the HP-UX auxiliary header must precede all other
      auxiliary headers.  The following declarations are found in
      <aouthdr.h>.

	   struct aux_id {
	       unsigned int  mandatory : 1;  /* reserved */
	       unsigned int  copy : 1;	     /* reserved */
	       unsigned int  append : 1;     /* reserved */
	       unsigned int  ignore : 1;     /* reserved */
	       unsigned int  reserved : 12;  /* reserved */
	       unsigned int  type : 16;	     /* aux hdr type */
	       unsigned int  length;	     /* sizeof rest of aux hdr */
	   };

	   /* Values for the aux_id.type field */
	   #define HPUX_AUX_ID 4
	   #define VERSION_AUX_ID 6
	   #define COPYRIGHT_AUX_ID 9
	   #define SHLIB_VERSION_AUX_ID 10

	   struct som_exec_auxhdr {	    /* HP-UX auxiliary header */
	       struct	aux_id som_auxhdr;  /* aux header id */
	       long	      exec_tsize;   /* text size */
	       long	      exec_tmem;    /* start address of text */



 Hewlett-Packard Company	    - 4 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




	       long	      exec_tfile;   /* file ptr to text */
	       long	      exec_dsize;   /* data size */
	       long	      exec_dmem;    /* start address of data */
	       long	      exec_dfile;   /* file ptr to data */
	       long	      exec_bsize;   /* bss size */
	       long	      exec_entry;   /* address of entry point */
	       long	      exec_flags;   /* loader flags */
	       long	      exec_bfill;   /* bss initialization value */
	   };

	   /* Values for exec_flags */
	   #define TRAP_NIL_PTRS    01

	   struct user_string_aux_hdr {	       /* Version string auxiliary header */
	       struct aux_id  header_id;       /* aux header id */
	       unsigned int   string_length;   /* strlen(user_string) */
	       char	      user_string[1];  /* user-defined string */
	   };

	   struct copyright_aux_hdr {	      /* Copyright string auxiliary header */
	       struct aux_id  header_id;      /* aux header id */
	       unsigned int   string_length;  /* strlen(user_string) */
	       char	      copyright[1];   /* user-defined string */
	   };
	   struct shlib_version_aux_hdr {
	       struct aux_id  header_id;      /* aux header id */
	       short  version;		      /* version number */
	   };

    Space Dictionary
      The space dictionary consists of a sequence of space records as
      defined in <spacehdr.h>.

      struct space_dictionary_record {"
	  union name_pt name;		    /* index to space name */
	  unsigned int	is_loadable: 1;	    /* space is loadable */
	  unsigned int	is_defined: 1;	    /* space is defined within file */
	  unsigned int	is_private: 1;	    /* space is not sharable */
	  unsigned int	reserved: 13;	    /* reserved */
	  unsigned int	sort_key: 8;	    /* sort key for space */
	  unsigned int	reserved2: 8;	    /* reserved */
	  int		space_number;	    /* space index */
	  int		subspace_index;	    /* index to first subspace */
	  unsigned int	subspace_quantity;  /* # of subspaces in space */
	  int		loader_fix_index;	 /* reserved */
	  unsigned int	loader_fix_quantity;	 /* reserved */
	  int		init_pointer_index;	 /* reserved */
	  unsigned int	init_pointer_quantity;	 /* reserved */
      };





 Hewlett-Packard Company	    - 5 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      The strings for the space names are contained in the space strings
      table, 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 characters 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.

	   union name_pt {
	       char	     *n_name;
	       unsigned int   n_strx;
	   };

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

      struct subspace_dictionary_record {
	  int		space_index;
	  unsigned int	access_control_bits: 7; /* reserved */
	  unsigned int	memory_resident: 1;	/* reserved */
	  unsigned int	dup_common: 1;		/* COBOL-style common */
	  unsigned int	is_common: 1;		/* subspace is a common block */
	  unsigned int	is_loadable: 1;		/* subspace is loadable */
	  unsigned int	quadrant: 2;		/* reserved */
	  unsigned int	initially_frozen: 1;	/* reserved */
	  unsigned int	is_first: 1;		/* reserved */
	  unsigned int	code_only: 1;		/* subspace contains only code */
	  unsigned int	sort_key: 8;		/* subspace sort key */
	  unsigned int	replicate_init: 1;	/* reserved */
	  unsigned int	continuation: 1;	/* reserved */
	  unsigned int	reserved: 6;		/* reserved */
	  int		file_loc_init_value;	/* file location or init value */
	  unsigned int	initialization_length;	/* length of initialization */
	  unsigned int	subspace_start;		/* starting offset */
	  unsigned int	subspace_length;	/* total subspace length */
	  unsigned int	reserved2: 16;		/* reserved */
	  unsigned int	alignment: 16;		/* alignment required */
	  union name_pt name;			/* index of subspace name */
	  int		fixup_request_index;	/* index to first fixup */
	  unsigned int	fixup_request_quantity; /* # of fixup requests */
      };

    Symbol Table
      The symbol table consists of a sequence of entries described by the
      structure shown below, from <syms.h>.  Strings for symbol and
      qualifier names are contained in the symbol strings table, whose



 Hewlett-Packard Company	    - 6 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      structure is identical with the space strings table.

	   struct symbol_dictionary_record {
	       unsigned int    hidden: 1;	    /* reserved */
	       unsigned int    symbol_type: 7;	    /* symbol type */
	       unsigned int    symbol_scope: 4;	    /* symbol value */
	       unsigned int    check_level: 3;	    /* type checking level */
	       unsigned int    must_qualify: 1;	    /* qualifier required */
	       unsigned int    initially_frozen: 1; /* reserved */
	       unsigned int    memory_resident: 1;  /* reserved */
	       unsigned int    is_common: 1;	    /* common block */
	       unsigned int    dup_common: 1;	    /* COBOL-style common */
	       unsigned int    xleast: 2;	    /* reserved */
	       unsigned int    arg_reloc: 10;	    /* parameter relocation bits */
	       union name_pt   name;		    /* index to symbol name */
	       union name_pt   qualifier_name;	    /* index to qual name */
	       unsigned int    symbol_info;	    /* subspace index */
	       unsigned int    symbol_value;	    /* symbol value */
	   };

	   /* Values for symbol_type */
	   #define ST_NULL	   0	/* unused symbol entry */
	   #define ST_ABSOLUTE	   1	/* non-relocatable symbol */
	   #define ST_DATA	   2	/* data symbol */
	   #define ST_CODE	   3	/* generic code symbol */
	   #define ST_PRI_PROG	   4	/* program entry point */
	   #define ST_SEC_PROG	   5	/* secondary prog entry point*/
	   #define ST_ENTRY	   6	/* procedure entry point */
	   #define ST_STORAGE	   7	/* storage request */
	   #define ST_STUB	   8	/* reserved */
	   #define ST_MODULE	   9	/* Pascal module name */
	   #define ST_SYM_EXT	   10	/* symbol extension record */
	   #define ST_ARG_EXT	   11	/* argument extension record */
	   #define ST_MILLICODE	   12	/* millicode entry point */
	   #define ST_PLABEL	   13	/* reserved */
	   #define ST_OCT_DIS	   14	/* reserved */
	   #define ST_MILLI_EXT	   15	/* reserved */

	   /* Values for symbol_scope */
	   #define SS_UNSAT	   0	/* unsatisfied reference */
	   #define SS_EXTERNAL	   1	/* reserved */
	   #define SS_LOCAL	   2	/* local symbol */
	   #define SS_UNIVERSAL	   3	/* global symbol */

      The meaning of the symbol value depends on the symbol type.  For the
      code symbols (generic code, program entry points, procedure and
      millicode 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 generally 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
      symbols, the symbol value is simply the address of the symbol.  For



 Hewlett-Packard Company	    - 7 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      storage requests, the symbol value is the number of bytes requested;
      the linker allocates space for the largest request for each symbol in
      the $BSS$ 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,
      extension records follow symbols that define and reference procedure
      entry points and global variables.  The first extension record, the
      symbol extension record, 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 argument extension
      records 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.

	   union arg_descriptor {
	       struct {
	       unsigned int    reserved: 3;    /* not used */
	       unsigned int    packing: 1;     /* reserved */
	       unsigned int    alignment: 4;   /* byte alignment */
	       unsigned int    reserved2: 1;   /* not used */
	       unsigned int    mode: 3;	       /* use of symbol */
	       unsigned int    structure: 4;   /* structure of symbol */
	       unsigned int    hash: 1;	       /* set if arg_type is hashed */
	       int	       arg_type: 15;   /* data type */
	       }	       arg_desc;
	       unsigned int    word;
	   };

	   struct symbol_extension_record {
	       unsigned int    type:	     8;	       /* always ST_SYM_EXT */
	       unsigned int    max_num_args: 8;	       /* max # of parameters */
	       unsigned int    min_num_args: 8;	       /* min # of parameters */
	       unsigned int    num_args:     8;	       /* actual # of parameters */
	       union arg_descriptor symbol_desc;       /* symbol type desc. */
	       union arg_descriptor argument_desc[3];  /* first 3 parameters */
	   };

	   struct argument_desc_array {
	       unsigned int    type:	  8;	       /* always ST_ARG_EXT */
	       unsigned int    reserved: 24;	       /* not used */
	       union arg_descriptor argument_desc[4];  /* next 4 parameters */
	   };




 Hewlett-Packard Company	    - 8 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      The values for the alignment, mode, structure, and arg_type (when the
      data type is not hashed) fields are given in the following table.

     value   alignment	 mode		   structure	   arg_type
     _______________________________________________________________________
       0     byte	 any		   any		   any
       1     half-word	 value parm	   scalar	   void
       2     word	 reference parm	   array	   signed byte
       3     dbl word	 value-result	   struct	   unsigned byte
       4		 name		   pointer	   signed short
       5		 variable	   long ptr	   unsigned short
       6     64-byte	 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     page					   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 (r26-r23) instead of on the stack, and the return value is
      returned in r29.	Floating-point parameters in this range are passed
      instead in floating-point registers (fr4-fr7) and a floating-point
      value is returned in fr4.	 The parameter relocation 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
      parameter word should be marked 11 and the even-numbered parameter
      word should be marked 10.	 Double-precision return values are simply
      marked 11.





 Hewlett-Packard Company	    - 9 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      Every procedure call is tagged with a similar set of bits (see
      Relocation 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 VERSION_ID is found in older object files, and the
      constant NEW_VERSION_ID 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 <reloc.h>.

	   struct fixup_request_record {
	       unsigned int    need_data_ref:	1;     /* reserved */
	       unsigned int    arg_reloc:      10;     /* parameter relocation bits */
	       unsigned int    expression_type: 5;     /* how to compute value */
	       unsigned int    exec_level:	2;     /* reserved */
	       unsigned int    fixup_format:	6;     /* how to deposit bits */
	       unsigned int    fixup_field:	8;     /* field to extract */
	       unsigned int    subspace_offset;	       /* subspace offset of word */
	       unsigned int    symbol_index_one;       /* index of first symbol */
	       unsigned int    symbol_index_two;       /* index of second symbol */
	       int	       fixup_constant;	       /* constant */
	   };

	   /* Values for expression_type */
	   #define e_one      0	 /* symbol1 + constant */
	   #define e_two      1	 /* symbol1 - symbol2 + constant */
	   #define e_pcrel    2	 /* symbol1 - pc + constant */
	   #define e_con      3	 /* constant */
	   #define e_plabel   7	 /* symbol1 + constant */
	   #define e_abs     18	 /* reserved */





 Hewlett-Packard Company	   - 10 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




	   /* Values for fixup_field (assembler mnemonics shown) */
	   #define e_fsel     0	 /* F': no change */
	   #define e_lssel    1	 /* LS': inverse of RS' */
	   #define e_rssel    2	 /* RS': rightmost 11 bits, signed */
	   #define e_lsel     3	 /* L': leftmost 21 bits */
	   #define e_rsel     4	 /* R': rightmost 11 bits */
	   #define e_ldsel    5	 /* LD': inverse of RD' */
	   #define e_rdsel    6	 /* RD': rightmost 11 bits, filled left with ones */
	   #define e_lrsel    7	 /* LR': L' with  rounded" constant */"
	   #define e_rrsel    8	 /* RR': R' with  rounded" constant */"

	   /* Values for fixup_format (typical instructions shown) */"
	   #define i_exp14    0	 /* 14-bit immediate (LDW, STW) */
	   #define i_exp21    1	 /* 21-bit immediate (LDIL, ADDIL) */
	   #define i_exp11    2	 /* 11-bit immediate (ADDI, SUBI) */
	   #define i_rel17    3	 /* 17-bit pc-relative (BL) */
	   #define i_rel12    4	 /* 12 bit pc-relative (COMBT, COMBF, etc.) */
	   #define i_data     5	 /* whole word */
	   #define i_none     6	 /* not used */
	   #define i_abs17    7	 /* 17-bit absolute (BE, BLE) */
	   #define i_milli    8	 /* 17-bit millicode call (BLE) */
	   #define i_break    9	 /* reserved (no effect on HP-UX) */

      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 a.out 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 uninitialized 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 <reloc.h> 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.

      R_NO_RELOCATION
		     Copy L bytes with no relocation.





 Hewlett-Packard Company	   - 11 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      R_ZEROES	     Insert L zero bytes into the output subspace.

      R_UNINIT	     Skip L bytes in the output subspace.

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

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

      R_DATA_PLABEL  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).

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

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

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

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

      R_DP_RELATIVE  Copy one instruction word with relocation.	 The word is
		     assumed to be a dp-relative load or store instruction
		     (for example, ADDIL, LDW, STW).  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 $global$.  By convention, the value
		     of $global$ is always contained in register 27.
		     Instructions other than LDIL and ADDIL may have a small
		     constant in the displacement field of the instruction.

      R_DLT_REL	     Copy one instruction word with relocation.	 The word is
		     assumed to be a register-r18-relative load or store
		     instruction (for example, LDW, LDO, STW).	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 position-
		     independent code) for the symbol S.



 Hewlett-Packard Company	   - 12 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      R_CODE_ONE_SYMBOL
		     Copy one instruction word with relocation.	 The word is
		     assumed to be an instruction referring to symbol S (for
		     example, LDIL, LDW, BE).  Instructions other than LDIL
		     and ADDIL may have a small constant in the displacement
		     field of the instruction.

      R_MILLI_REL    Copy one instruction word with relocation.	 The word is
		     assumed to be a short millicode call instruction (for
		     example, BLE).  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.

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

      R_BREAKPOINT   Copy one instruction word conditionally.  On HP-UX, the
		     linker always replaces the word with a NOP instruction.

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

      R_ALT_ENTRY    Define an alternate procedure entry point.

      R_EXIT	     Define a procedure exit point.

      R_BEGIN_TRY    Define the beginning of a try/recover region.

      R_END_TRY	     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.

      R_BEGIN_BRTAB  Define the beginning of a branch table.

      R_END_BRTAB    Define the end of a branch table.

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




 Hewlett-Packard Company	   - 13 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




      R_STATEMENT    Define the beginning of statement number N.

      R_SEC_STATEMENT
		     Define the beginning of a secondary statement number N.

      R_DATA_EXPR    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.

      R_CODE_EXPR    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.

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

      R_LSEL	     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.

      R_RSEL	     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.

      R_N_MODE	     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.

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

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

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

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

      R_TRANSLATED   Toggle ``translated'' mode.  This fixup request is
		     generated only by the linker during a relocatable link



 Hewlett-Packard Company	   - 14 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




		     to indicate a subspace that was originally read from an
		     old-format relocatable object file.

      R_COMP1	     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.
			  R_PUSH_PCON1	      Push the (positive) constant
					      V.
			  R_PUSH_DOT	      Push the current virtual
					      address.
			  R_MAX		      Pop A and B, then push max(A,
					      B).
			  R_MIN		      Pop A and B, then push min(A,
					      B).
			  R_ADD		      Pop A and B, then push A + B.
			  R_SUB		      Pop A and B, then push B - A.
			  R_MULT	      Pop A and B, then push A * B.
			  R_DIV		      Pop A and B, then push B / A.
			  R_MOD		      Pop A and B, then push B % A.
			  R_AND		      Pop A and B, then push A & B.
			  R_OR		      Pop A and B, then push A | B.
			  R_XOR		      Pop A and B, then push A XOR
					      B.
			  R_NOT		      Replace A with its complement.
			  R_LSHIFT	      If C = 0, pop A and B, then
					      push B << A.  Otherwise,
					      replace A with A << C.
			  R_ARITH_RSHIFT      If C = 0, pop A and B, then
					      push B >> A.  Otherwise,
					      replace A with A >> C.  The
					      shifting is done with sign
					      extension.
			  R_LOGIC_RSHIFT      If C = 0, pop A and B, then
					      push B >> A.  Otherwise,
					      replace A with A >> C.  The
					      shifting is done with zero
					      fill.
			  R_PUSH_NCON1	      Push the (negative) constant
					      V.

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




 Hewlett-Packard Company	   - 15 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




			  R_PUSH_NCON2	      Push the (negative) constant
					      V.

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

      R_PREV_FIXUP   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.

      R_RESERVED     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 * 4; M = (B1 + 1) * L
			 44	    5	  L = B1 * 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



 Hewlett-Packard Company	   - 16 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




   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	    2	  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 = B1 * 4
			 186	    4	  R = 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 = B1
			 203	    3	  V = B2
			 204	    4	  V = 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);



 Hewlett-Packard Company	   - 17 -     HP-UX Release 9.0: August 1992






 a.out_800(4)		Series 700/800 Implementation		a.out_800(4)




					  S = V & 0xffffff
   R_PREV_FIXUP	       211-214	    1	  X = D
   R_SEC_STMT		 215	    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 general
      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 contribution is the pair of bits for the return value, which
      are not modified.	 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 second word.	 Similarly, the third contribution is formed
      based on the third and fourth parameter words.  The second
      contribution is multiplied 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
      produce 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.

	   struct compilation_unit {
	       union name_pt	 name;
	       union name_pt	 language_name;
	       union name_pt	 product_id;
	       union name_pt	 version_id;
	       int		 reserved;
	       struct sys_clock	 compile_time;
	       struct sys_clock	 source_time;
	   };

 SEE ALSO
      as_300(1), as_800(1), cc(1), ld(1), nm_300(1), nm_800(1), strip(1),
      crt0(3), end(3C), a.out_300(4), magic(4).









 Hewlett-Packard Company	   - 18 -     HP-UX Release 9.0: August 1992



