elf man page on HP-UX

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

elf(3E)								       elf(3E)

NAME
       elf - object file access library

SYNOPSIS
       [flag... ] file...  [library] ...

DESCRIPTION
       Functions  in the ELF access library let a program manipulate ELF (Exe‐
       cutable and Linking Format) object files, archive  files,  and  archive
       members.	  The  header file provides type and function declarations for
       all library services.

       Programs communicate with many of the higher-level  routines  using  an
       That  is,  when	the program starts working with a file, creates an ELF
       descriptor through which the program  manipulates  the  structures  and
       information  in	the  file.   These ELF descriptors can be used both to
       read and to write files.	 After the program establishes an ELF descrip‐
       tor  for	 a  file, it may then obtain section descriptors to manipulate
       the sections of the file (see elf_getscn(3E)).  Sections hold the  bulk
       of  an  object  file's real information, such as text, data, the symbol
       table, and so on.  A section descriptor ``belongs'' to a particular ELF
       descriptor,  just  as  a	 section  belongs  to  a  file.	 Finally, data
       descriptors are available through  section  descriptors,	 allowing  the
       program	to  manipulate	the  information associated with a section.  A
       data descriptor ``belongs'' to a section descriptor.

       Descriptors provide private handles to a file and its pieces.  In other
       words,  a  data	descriptor  is associated with one section descriptor,
       which is associated with one ELF descriptor, which is  associated  with
       one  file.   Although descriptors are private, they give access to data
       that may be shared.  Consider programs that combine input files,	 using
       incoming	 data  to create or update another file.  Such a program might
       get data descriptors for an input and an output section.	 It then could
       update  the  output  descriptor	to  reuse the input descriptor's data.
       That is, the descriptors are distinct, but they could share the associ‐
       ated  data bytes.  This sharing avoids the space overhead for duplicate
       buffers and the performance overhead for copying data unnecessarily.

   File Classes
       ELF provides a framework in which to define a family of	object	files,
       supporting  multiple  processors	 and architectures.  An important dis‐
       tinction among object files is the class , or capacity,	of  the	 file.
       The  32-bit  class  supports architectures in which a 32-bit object can
       represent addresses, file sizes, and so forth, as in the following.

		       Name	       Purpose
		       ────────────────────────────────────────
		       Elf32_Addr      Unsigned address
		       Elf32_Half      Unsigned medium integer
		       Elf32_Off       Unsigned file offset
		       Elf32_Sword     Signed large integer
		       Elf32_Word      Unsigned large integer
		       unsigned char   Unsigned small integer

       Other classes will be defined  as  necessary,  to  support  larger  (or
       smaller)	 machines.   Some library services deal only with data objects
       for a specific class, while others are  class-  independent.   To  make
       this distinction clear, library function names reflect their status, as
       described below.

   Data Representations
       Conceptually, two parallel sets of objects  support  cross  compilation
       environments.   One  set	 corresponds to file contents, while the other
       set corresponds to the native memory image of the program  manipulating
       the  file.   Type  definitions supplied by the header files work on the
       native machine, which may have different	 data  encodings  (size,  byte
       order,  and  so forth) than the target machine.	Although native memory
       objects should be at least as big as the file objects (to avoid	infor‐
       mation  loss),  they may be bigger if that is more natural for the host
       machine.

       Translation facilities exist to convert between file and memory	repre‐
       sentations.   Some  library  routines convert data automatically, while
       others leave conversion as the program's responsibility.	  Either  way,
       programs	 that  create  object  files  must write file-typed objects to
       those files; programs that read object files must take a similar	 view.
       See elf_xlate(3E) and elf_fsize(3E) for more information.

       Programs	 may  translate	 data explicitly, taking full control over the
       object file layout and semantics.  If the program prefers not  to  have
       and  exercise  complete	control,  the  library provides a higher-level
       interface that hides many object file details.  and  related  functions
       let  a  program	deal  with the native memory types, converting between
       memory objects and their file equivalents automatically when reading or
       writing an object file.

   ELF Versions
       Object  file  versions  allow ELF to adapt to new requirements.	Three-
       independent-versions can be important to a program.  First, an applica‐
       tion  program  knows about a particular version by virtue of being com‐
       piled with certain header files.	 Second, the access library  similarly
       is  compiled  with  header  files  that control what versions it under‐
       stands.	Third, an ELF object file holds a value identifying  its  ver‐
       sion,  determined by the ELF version known by the file's creator.  Ide‐
       ally, all three versions would be the same, but they may differ.

       If a program's version is newer than the access	library,  the  program
       might  use  information	unknown	 to the library.  Translation routines
       might not work properly, leading to undefined behavior.	This condition
       merits installing a new library.

       The library's version might be newer than the program's and the file's.
       The library understands old versions, thus avoiding compatibility prob‐
       lems in this case.

       Finally, a file's version might be newer than either the program or the
       library understands.  The program might or might not be able to process
       the  file properly, depending on whether the file has extra information
       and whether that information can be safely ignored.   Again,  the  safe
       alternative  is	to  install  a new library that understands the file's
       version.

       To accommodate these differences, a program must use to pass  its  ver‐
       sion  to	 the  library,	thus  establishing the for the process.	 Using
       this, the library accepts data from and presents data to the program in
       the  proper  representations.   When the library reads object files, it
       uses each file's version to interpret the data. When writing  files  or
       converting  memory  types to the file equivalents, the library uses the
       program's working version for the file data.

   System Services
       As mentioned above, and related routines provide a higher-level	inter‐
       face  to ELF files, performing input and output on behalf of the appli‐
       cation program.	These routines assume a program can hold entire	 files
       in  memory,  without  explicitly using temporary files.	When reading a
       file, the library routines bring the data into memory and perform  sub‐
       sequent	operations  on	the  memory copy.  Programs that read or write
       large object files with this model must execute on  a  machine  with  a
       large  process virtual address space.  If the underlying operating sys‐
       tem limits the number of open files, a program can use to retrieve  all
       necessary  data	from  the file, allowing the program to close the file
       descriptor and reuse it.

       Although the interfaces are convenient and efficient for many programs,
       they  might  be inappropriate for some.	In those cases, an application
       may invoke the data translation routines directly.  These routines per‐
       form no input or output, leaving that as the application's responsibil‐
       ity.  By assuming a larger share of the job,  an	 application  controls
       its input and output model.

   Library Names
       Names associated with the library take several forms.

	      These class-independent names perform some service,
				name, for the program.

	      Service names with an embedded class,
				here,indicate  they  work  only for the desig‐
				nated class of files.

	      Service names with an embedded class,
				here,indicate they work only  for  the	desig‐
				nated class of files.

	      Data types can be class-independent as well, distinguished by
				Type.

	      Class-dependent data types have an embedded class name,
				here.

	      Class-dependent data types have an embedded class name,
				here.

	      Several functions take commands that control their actions.
				These  values  are members of the enumeration;
				they range from zero through

	      Several functions take flags that control
				library status and/or actions.	Flags are bits
				that may be combined.

	      These constants give the file sizes in bytes
				of the basic ELF types for the 32-bit class of
				files.	See for more information.

	      These constants give the file sizes in bytes
				of the basic ELF types for the 64-bit class of
				files.	See for more information.

	      The function	identifies the KIND of file associated with an
				ELF descriptor.	 These values are  members  of
				the enumeration; they range from zero through

	      When a service function, such as
				deals  with multiple types, names of this form
				specify the desired TYPE.  Thus, for  example,
				is  directly  related to These values are mem‐
				bers of the enumeration; they range from  zero
				through

   Note
       Information  in the ELF header files is separated into common parts and
       processor-specific parts.  A program can make a processor's information
       available  by including the appropriate header file: where NAME matches
       the processor name as used in the ELF file header.

				 Symbol	  Processor
				 ───────────────────
				 parisc	  PA RISC

       Other processors will be added to the table as  necessary.   To	illus‐
       trate, a program could use the following code to ``see'' the processor-
       specific information for the WE 32100.

       Without the definition, only the common ELF information would be	 visi‐
       ble.

SEE ALSO
       a.out(4),     ar(4),    elf_begin(3E),	 elf_cntl(3E),	  elf_end(3E),
       elf_error(3E),	  elf_fill(3E),	     elf_flag(3E),	elf_fsize(3E),
       elf_getarhdr(3E),  elf_getarsym(3E),  elf_getbase(3E), elf_getdata(3E),
       elf_getehdr(3E),	 elf_getident(3E),  elf_getphdr(3E),   elf_getscn(3E),
       elf_getshdr(3E),	     elf_hash(3E),     elf_kind(3E),	 elf_next(3E),
       elf_rand(3E), elf_rawfile(3E), elf_strptr(3E), elf_update(3E), elf_ver‐
       sion(3E), elf_xlate(3E).

								       elf(3E)
[top]

List of man pages available for HP-UX

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

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

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