Unix/Linux Go Back    


NetBSD 6.1.5 - man page for ld.elf_so (netbsd section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


LD.ELF_SO(1)			   BSD General Commands Manual			     LD.ELF_SO(1)

NAME
     ld.elf_so -- run-time link-editor (linker)

DESCRIPTION
     ld.elf_so is a self-contained, position independent program image providing run-time support
     for loading and link-editing shared objects into a process' address space.  It uses informa-
     tion stored in data structures within the binary (see elf(5)) and environment variables to
     determine which shared objects are needed.  These shared objects are loaded at a convenient
     virtual address using the mmap(2) system call.  After all shared objects have been success-
     fully loaded, ld.elf_so proceeds to resolve external references from both the main program
     and all objects loaded.  Once all required references are resolved control is passed to the
     program via its entry point.

   Startup
     On the execution of a dynamically linked binary the kernel will load the program and its
     run-time linker as specified in the PT_INTERP section in the program header.  At this point,
     instead of passing control directly to the program, the kernel passes control to the speci-
     fied linker.  An auxiliary vector of information is passed that includes the address of the
     program header, the size of each entry in the header, and the number of entries.  The entry
     point of the program and the base address of where ld.elf_so is loaded is also supplied.

   Finding objects
     Each elf(5) object file may contain information in its dynamic (PT_DYNAMIC) section about
     which shared objects it requires (often referred to as dependencies).  These dependencies
     are specified in the optional DT_NEEDED entry within the dynamic section.	Each DT_NEEDED
     entry refers to a filename string of the shared object that is to be searched for.

     The linker will search for libraries in three lists of paths:

     1.   A user defined list of paths as specified in LD_LIBRARY_PATH and ld.so.conf(5).

	  The use of ld.so.conf should be avoided as the setting of a global search path can
	  present a security risk.

     2.   A list of paths specified within a shared object using a DT_RPATH entry in the dynamic
	  section.  This is defined at shared object link time.

     3.   The list of default paths which is set to /usr/lib.

     ld.elf_so will expand the following variables if present in the paths:

     $HWCAP	Processor hardware capabilities, for example FPU, MMX, SSE.  Currently unimple-
		mented.

     $ISALIST	List of instructions sets this processor can execute.  Currently unimplemented.

     $ORIGIN	The directory of the main object.  Implemented in ld.elf_so but the kernel sup-
		port is currently disabled.

     $OSNAME	The value of the kern.ostype sysctl(3).

     $OSREL	The value of the kern.osrelease sysctl(3).

     $PLATFORM	The value of the hw.machine_arch sysctl(3).

     Both ${VARIABLE} and $VARIABLE are recognized.

     The filename string can be considered free form, however, it will almost always take the
     form lib<name>.so.<number>, where name specifies the 'library' name and number is conceptu-
     ally the library's major version number.

     This name and another of the form lib<name>.so are normally symbolic links to the real
     shared object which has a filename of the form lib<name>.so.<major>.<minor>[.<teeny>].  This
     naming convention allows a versioning scheme similar to a.out(5).

   Relocation
     ld.elf_so will perform all necessary relocations immediately except for relocations relating
     to the Procedure Linkage Table (PLT).  The PLT is used as a indirection method for procedure
     calls to globally defined functions.  It allows, through the use of intermediate code, the
     delayed binding of a call to a globally defined function to be performed at procedure call
     time.  This 'lazy' method is the default (see LD_BIND_NOW).

   Initialization
     A mechanism is provided for initialization and termination routines to be called, on a per-
     object basis before execution of the program proper begins or after the program has com-
     pleted.  This gives a shared object an opportunity to perform any extra set-up or completion
     work.

     The DT_INIT and DT_FINI entries in the dynamic section specify the addresses of the initial-
     ization and termination functions, respectively, for the shared object.  ld.elf_so arranges
     for each initialization function to be called before control is passed to the program and
     for the termination functions to be called by using atexit(3).

     This mechanism is exploited by the system-supplied constructor initialization and destructor
     code located in /usr/lib/crtbeginS.o and /usr/lib/crtendS.o.  These files are automatically
     included by cc(1) and c++(1) in the list of object-code files passed to ld(1) when building
     a shared C or C++ object.

ENVIRONMENT
     If the following environment variables exist they will be used by ld.elf_so.

     LD_LIBRARY_PATH  A colon separated list of directories, overriding the default search path
		      for shared libraries.

     LD_PRELOAD       A colon or space separated list of shared object filenames to be loaded
		      after the main program but before its shared object dependencies.  Space is
		      allowed as a separator for backwards compatibility only.	Support may be
		      removed in a future release and should not be relied upon.

     LD_BIND_NOW      If defined immediate binding of Procedure Link Table (PLT) entries is per-
		      formed instead of the default lazy method.

     LD_DEBUG	      If defined a variety of debug information will be written to the standard
		      error of an dynamically linked executed when it is run.  This variable is
		      only recognized if ld.elf_so was compiled with debugging support (-DDEBUG).

FILES
     /etc/ld.so.conf  library location hints supplied by the system administrator.

SEE ALSO
     ld(1), ld.aout_so(1), dlfcn(3), elf(5)

HISTORY
     The ELF shared library model employed first appeared in Sys V R4.

     The path expansion variables first appeared in Solaris 10, and in NetBSD 5.0.

SECURITY CONSIDERATIONS
     The environment variables LD_LIBRARY_PATH and LD_PRELOAD are not honored when executing in a
     set-user-ID or set-group-ID environment.  This action is taken to prevent malicious substi-
     tution of shared object dependencies or interposition of symbols.

BSD					December 17, 2010				      BSD
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 06:38 AM.