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

FreeBSD Manual Pages

  
 
  

home | help
a.out(4)							      a.out(4)

NAME
       a.out - assembler and link editor output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       For  procedure  entry  points, the parameter relocation bits define the
       locations of the	formal parameters and the return value.	 Normally, the
       first  four words of the	parameter list are passed in general registers
       instead of on the stack,	and the	return value is	returned in  Floating-
       point  parameters  in  this  range are passed instead in	floating-point
       registers and a floating-point value is returned	in The parameter relo-
       cation  bits consist of five pairs of bits that describe	the first four
       words of	the parameter list and the return value.  The leftmost pair of
       bits describes the first	parameter word,	and the	rightmost pair of bits
       describes the return value.  The	meanings of these bits	are  shown  in
       the following table.

		  |
	     Bits | Meaning
	     -----+------------------------------------------------------
	      00  | No parameter or return value
	      01  | Parameter or return	value in general register
	      10  | Parameter or return	value in floating-point	register
	      11  | Double-precision floating-point value

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

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

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

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

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

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

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

       Insert L	zero bytes into	the output subspace.

       Skip L bytes in the output subspace.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       Define an alternate procedure entry point.

       Define a	procedure exit point.

       Define the beginning of a try/recover region.

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

       Define the beginning of a branch	table.

       Define the end of a branch table.

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

       Define the beginning of statement number	N.

       Define the beginning of a secondary statement number N.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     Mnemonic		 Opcodes   Length   Parameters
     -----------------------------------------------------------------------------
     R_NO_RELOCATION	   0-23	      1	    L =	(D+1) *	4
			  24-27	      2	    L =	(D__8 +	B1 + 1)	* 4
			  28-30	      3	    L =	(D__16 + B2 + 1) * 4
			   31	      4	    L =	B3 + 1
     R_ZEROES		   32	      2	    L =	(B1 + 1) * 4
			   33	      4	    L =	B3 + 1
     R_UNINIT		   34	      2	    L =	(B1 + 1) * 4
			   35	      4	    L =	B3 + 1
     R_RELOCATION	   36	      1	    none
     R_DATA_ONE_SYMBOL	   37	      2	    S =	B1
			   38	      4	    S =	B3
     R_DATA_PLABEL	   39	      2	    S =	B1
			   40	      4	    S =	B3
     R_SPACE_REF	   41	      1	    none
     R_REPEATED_INIT	   42	      2	    L =	4; M = (B1 + 1)	* 4
			   43	      3	    L =	(B1 + 1) * 4; M	= (B1 +	1) * L
			   44	      5	    L =	(B1 + 1) * 4; M	= (B3 +	1) * 4
			   45	      8	    L =	B3 + 1;	M = B4 + 1
     R_PCREL_CALL	  48-57	      2	    R =	rbits1(D); S = B1
			  58-59	      3	    R =	rbits2(D__8 + B1); S = B1
			  60-61	      5	    R =	rbits2(D__8 + B1); S = B3
     R_ABS_CALL		  64-73	      2	    R =	rbits1(D); S = B1
			  74-75	      3	    R =	rbits2(D__8 + B1); S = B1
			  76-77	      5	    R =	rbits2(D__8 + B1); S = B3

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

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

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

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

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

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

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

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

								      a.out(4)

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