Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
a.out(4)		   Kernel Interfaces Manual		      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) de-
       scribes.	  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''  de-
       scribing	 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 in-
       formation 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  im-
       age  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 du-
       plication is necessary.	The stack is  automatically  extended  as  re-
       quired.	The data segment is extended as	requested by the brk(2)	system
       call.

   SOM a.out
       The file	name is	the default file name for the output file from the as-
       sembler (see as(1)), compilers, and the linker (see ld(1)).  The	assem-
       bler and	compilers create relocatable object files, ready for input  to
       the  linker.  The linker	creates	executable object files	and shared li-
       brary 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 de-
       fined  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 sub-
       space, 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 re-
       quested 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  re-
       served 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 de-
       fined 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 lo-
       cal 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 pa-
       rameters.   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 de-
       scribing	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_re-
       quest_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  re-
       quest  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 al-
	      ways 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  re-
	      locatable	 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  op-
	      code.   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  re-
       quests.
	      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 re-
	      quest, 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 li-
	      brary 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 to-
       gether.

   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)

NAME | SYNOPSIS | DESCRIPTION | FILES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=a.out&sektion=4&manpath=HP-UX+11.22>

home | help