xref: /netbsd-src/share/man/man5/link.5 (revision 7c7c171d130af9949261bc7dce2150a03c3d239c)
1.\"	$NetBSD: link.5,v 1.7 1998/02/06 06:11:55 perry Exp $
2.\"
3.\" Copyright (c) 1993 Paul Kranenburg
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. All advertising materials mentioning features or use of this software
15.\"    must display the following acknowledgement:
16.\"      This product includes software developed by Paul Kranenburg.
17.\" 3. The name of the author may not be used to endorse or promote products
18.\"    derived from this software without specific prior written permission
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
21.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
22.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
23.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
24.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
25.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
26.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
27.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
28.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
29.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
30.\"
31.Dd October 23, 1993
32.Dt LINK 5
33.Os
34.Sh NAME
35.Nm link
36.Nd dynamic loader and link editor interface
37.Sh SYNOPSIS
38.Fd #include <link.h>
39.Sh DESCRIPTION
40The include file
41.Aq Pa link.h
42declares several structures that are present in dynamically linked
43programs and libraries.
44The structures define the interface between several components of the
45link-editor and loader mechanism. The layout of a number of these
46structures within the binaries resembles the a.out format in many places
47as it serves such similar functions as symbol definitions (including the
48accompanying string table) and relocation records needed to resolve
49references to external entities. It also records a number of data structures
50unique to the dynamic loading and linking process. These include references
51to other objects that are required to complete the link-editing process and
52indirection tables to facilitate
53.Em Position Independent Code
54(PIC for short) to improve sharing of code pages among different processes.
55The collection of data structures described here will be refered to as the
56.Em Run-time Relocation Section (RRS)
57and is embedded in the standard text and data segments of the dynamically
58linked program or shared object image as the existing
59.Xr a.out
60format offers no room for it elsewhere.
61.Pp
62Several utilities co-operate to ensure that the task of getting a program
63ready to run can complete successfully in a way that optimizes the use
64of system resources. The compiler emits PIC code from which shared libraries
65can be built by
66.Xr ld 1 .
67The compiler also includes size information of any initialized data items
68through the .size assembler directive. PIC code differs from conventional code
69in that it accesses data variables through an indirection table, the
70Global Offset Table, by convention accessable by the reserved name
71.Em _GLOBAL_OFFSET_TABLE_ .
72The exact mechanism used for this is machine dependent, usually a machine
73register is reserved for the purpose. The rational behind this construct
74is to generate code that is independent of the actual load address. Only
75the values contained in the Global Offset Table may need updating at run-time
76depending on the load addresses of the various shared objects in the address
77space.
78.Pp
79Likewise, procedure calls to globally defined functions are redirected through
80the Procedure Linkage Table (PLT) residing in the data segment of the core
81image. Again, this is done to avoid run-time modifications to the text segment.
82.Pp
83The linker-editor allocates the Global Offset Table and Procedure Linkage Table
84when combining PIC object files into an image suitable for mapping into the
85process address space. It also collects all symbols that may be needed by the
86run-time link-editor and stores these along with the image's text and data bits.
87Another reserved symbol,
88.Em _DYNAMIC
89is used to indicate the presence of the run-time linker structures. Whenever
90_DYNAMIC is relocated to 0, there is no need to invoke the run-time
91link-editor. If this symbol is non-zero, it points at a data structure from
92which the location of the necessary relocation- and symbol information can
93be derived. This is most notably used by the start-up module,
94.Em crt0 .
95The _DYNAMIC structure is conventionally located at the start of the data
96segment of the image to which it pertains.
97.Pp
98.Sh DATA STRUCTURES
99The data structures supporting dynamic linking and run-time relocation
100reside both in the text and data segments of the image they apply to.
101The text segments contain read-only data such as symbols descriptions and
102names, while the data segments contain the tables that need to be modified by
103during the relocation process.
104.Pp
105The _DYNAMIC symbol references a
106.Fa _dynamic
107structure:
108.Bd -literal -offset indent
109struct	_dynamic {
110	int	d_version;
111	struct 	so_debug *d_debug;
112	union {
113		struct section_dispatch_table *d_sdt;
114	} d_un;
115	struct  ld_entry *d_entry;
116};
117.Ed
118.Bl -tag -width d_version
119.It Fa d_version
120This field provides for different versions of the dynamic linking
121implementation. The current version numbers understood by ld and ld.so are
122.Em LD_VERSION_SUN (3),
123which is used by the
124.Tn SunOS 4.x
125releases, and
126.Em LD_VERSION_BSD (8),
127which is currently in use by
128.Nx .
129.It Fa d_un
130Refers to a
131.Em d_version
132dependent data structure.
133.It Fa d_debug
134this field provides debuggers with a hook to access symbol tables of shared
135objects loaded as a result of the actions of the run-time link-editor.
136.It Fa d_entry
137this field is obsoleted by CRT interface version CRT_VERSION_BSD4, and is
138replaced by the crt_ldentry in
139.Fa crt_ldso .
140.El
141.Pp
142The
143.Fa section_dispatch_table
144structure is the main
145.Dq dispatcher
146table, containing offsets into the image's segments where various symbol
147and relocation information is located.
148.Bd -literal -offset indent
149struct section_dispatch_table {
150	struct	so_map *sdt_loaded;
151	long	sdt_sods;
152	long	sdt_paths;
153	long	sdt_got;
154	long	sdt_plt;
155	long	sdt_rel;
156	long	sdt_hash;
157	long	sdt_nzlist;
158	long	sdt_filler2;
159	long	sdt_buckets;
160	long	sdt_strings;
161	long	sdt_str_sz;
162	long	sdt_text_sz;
163	long	sdt_plt_sz;
164};
165.Ed
166.Pp
167.Bl -tag -width sdt_loaded
168.It Fa sdt_loaded
169A pointer to the first link map loaded (see below). This field is set by
170.Xr ld.so
171for the benefit of debuggers that may use it to load a shared object's
172symbol table.
173.It Fa sdt_sods
174The start of a (linked) list of shared object descriptors needed by
175.Em this
176object.
177.It Fa sdt_paths
178Library search rules. A colon separated list of directories corresponding
179to the
180.Fl R
181option of
182.Xr ld 1 .
183.It Fa sdt_got
184The location of the Global Offset Table within this image.
185.It Fa sdt_plt
186The location of the Procedure Linkage Table within this image.
187.It Fa sdt_rel
188The location of an array of
189.Fa relocation_info
190structures
191.Po
192see
193.Xr a.out 5
194.Pc
195specifying run-time relocations.
196.It Fa sdt_hash
197The location of the hash table for fast symbol lookup in this object's
198symbol table.
199.It Fa sdt_nzlist
200The location of the symbol table.
201.It Fa sdt_filler2
202Currently unused.
203.It Fa sdt_buckets
204The number of buckets in
205.Fa sdt_hash
206.It Fa sdt_strings
207The location of the symbol string table that goes with
208.Fa sdt_nzlist .
209.It Fa sdt_str_sz
210The size of the string table.
211.It Fa sdt_text_sz
212The size of the object's text segment.
213.It Fa sdt_plt_sz
214The size of the Procedure Linkage Table.
215.El
216.Pp
217A
218.Fa sod
219structure descibes a shared object that is needed
220to complete the link edit process of the object containing it.
221A list of such objects
222.Po
223chained through
224.Fa sod_next
225.Pc
226is pointed at
227by the
228.Fa sdt_sods
229in the section_dispatch_table structure.
230.Bd -literal -offset indent
231struct sod {
232	long	sod_name;
233	u_int	sod_library : 1,
234		sod_unused : 31;
235	short	sod_major;
236	short	sod_minor;
237	long	sod_next;
238};
239.Ed
240.Pp
241.Bl -tag -width sod_library
242.It Fa sod_name
243The offset in the text segment of a string describing this link object.
244.It Fa sod_library
245If set,
246.Fa sod_name
247specifies a library that is to be searched for by ld.so. The path name
248is obtained by searching a set of directories
249.Po
250see also
251.Xr ldconfig 8
252.Pc
253for a shared object matching
254.Em lib\&<sod_name>\&.so.n.m .
255If not set,
256.Fa sod_name
257should point at a full path name for the desired shared object.
258.It Fa sod_major
259Specifies the major version number of the shared object to load.
260.It Fa sod_minor
261Specifies the prefered minor version number of the shared object to load.
262.El
263.Pp
264The run-time link-editor maintains a list of structures called
265.Em link maps
266to keep track of all shared objects loaded into a process' address space.
267These structures are only used at run-time and do not occur within
268the text or data segment of an executable or shared library.
269.Bd -literal -offset indent
270struct so_map {
271	caddr_t	som_addr;
272	char 	*som_path;
273	struct	so_map *som_next;
274	struct	sod *som_sod;
275	caddr_t som_sodbase;
276	u_int	som_write : 1;
277	struct	_dynamic *som_dynamic;
278	caddr_t	som_spd;
279};
280.Ed
281.Bl -tag -width som_dynamic
282.It Fa som_addr
283The address at which the shared object associated with this link map has
284been loaded.
285.It Fa som_path
286The full path name of the loaded object.
287.It Fa som_next
288Pointer to the next link map.
289.It Fa som_sod
290The
291.Fa sod
292structure that was responsible for loading this shared object.
293.It Fa som_sodbase
294Tossed in later versions the run-time linker.
295.It Fa som_write
296Set if (some portion of) this object's text segment is currently writable.
297.It Fa som_dynamic
298Pointer to this object's
299.Fa _dynamic
300structure.
301.It Fa som_spd
302Hook for attaching private data maintained by the run-time link-editor.
303.El
304.Pp
305Symbol description with size. This is simply an
306.Fa nlist
307structure with one field
308.Pq Fa nz_size
309added. Used to convey size information on items in the data segment
310of shared objects. An array of these lives in the shared object's
311text segment and is addressed by the
312.Fa sdt_nzlist
313field of
314.Fa section_dispatch_table .
315.Bd -literal -offset indent
316struct nzlist {
317	struct nlist	nlist;
318	u_long		nz_size;
319#define nz_un		nlist.n_un
320#define nz_strx		nlist.n_un.n_strx
321#define nz_name		nlist.n_un.n_name
322#define nz_type		nlist.n_type
323#define nz_value	nlist.n_value
324#define nz_desc		nlist.n_desc
325#define nz_other	nlist.n_other
326};
327.Ed
328.Bl -tag -width nz_size
329.It Fa nlist
330.Po
331see
332.Xr nlist 5
333.Pc .
334.It Fa nz_size
335The size of the data represented by this symbol.
336.El
337.Pp
338A hash table is included within the text segment of shared object to
339to facilitate quick lookup of symbols during run-time link-editing.
340The
341.Fa sdt_hash
342field of the
343.Fa section_dispatch_table
344structure points at an array of
345.Fa rrs_hash
346structures:
347.Bd -literal -offset indent
348struct rrs_hash {
349	int	rh_symbolnum;		/* symbol number */
350	int	rh_next;		/* next hash entry */
351};
352.Ed
353.Pp
354.Bl -tag -width rh_symbolnum
355.It Fa rh_symbolnum
356The index of the symbol in the shared object's symbol table (as given by the
357.Fa ld_symbols
358field).
359.It Fa rh_next
360In case of collisions, this field is the offset of the next entry in this
361hash table bucket. It is zero for the last bucket element.
362.El
363The
364.Fa rt_symbol
365structure is used to keep track of run-time allocated commons
366and data items copied from shared objects. These items are kept on linked list
367and is exported through the
368.Fa dd_cc
369field in the
370.Fa so_debug
371structure (see below) for use by debuggers.
372.Bd -literal -offset indent
373struct rt_symbol {
374	struct nzlist		*rt_sp;
375	struct rt_symbol	*rt_next;
376	struct rt_symbol	*rt_link;
377	caddr_t			rt_srcaddr;
378	struct so_map		*rt_smp;
379};
380.Ed
381.Pp
382.Bl -tag -width rt_scraddr
383.It Fa rt_sp
384The symbol description.
385.It Fa rt_next
386Virtual address of next rt_symbol.
387.It Fa rt_link
388Next in hash bucket. Used by internally by ld.so.
389.It Fa rt_srcaddr
390Location of the source of initialized data within a shared object.
391.It Fa rt_smp
392The shared object which is the original source of the data that this
393run-time symbol describes.
394.El
395.Pp
396The
397.Fa so_debug
398structure is used by debuggers to gain knowledge of any shared objects
399that have been loaded in the process's address space as a result of run-time
400link-editing. Since the run-time link-editor runs as a part of process
401initialization, a debugger that wishes to access symbols from shared objects
402can only do so after the link-editor has been called from crt0.
403A dynamically linked binary contains a
404.Fa so_debug
405structure which can be located by means of the
406.Fa d_debug
407field in
408.Fa _dynamic .
409.Bd -literal -offset indent
410struct 	so_debug {
411	int	dd_version;
412	int	dd_in_debugger;
413	int	dd_sym_loaded;
414	char    *dd_bpt_addr;
415	int	dd_bpt_shadow;
416	struct rt_symbol *dd_cc;
417};
418.Ed
419.Pp
420.Bl -tag -width dd_in_debugger
421.It Fa dd_version
422Version number of this interface.
423.It Fa dd_in_debugger
424Set by the debugger to indicate to the run-time linker that the program is
425run under control of a debugger.
426.It Fa dd_sym_loaded
427Set by the run-time linker whenever it adds symbols by loading shared objects.
428.It Fa dd_bpt_addr
429The address were a breakpoint will be set by the run-time linker to
430divert control to the debugger. This address is determined by the start-up
431module,
432.Em crt0.o,
433to be some convenient place before the call to _main.
434.It Fa dd_bpt_shadow
435Contains the original instruction that was at
436.Fa dd_bpt_addr .
437The debugger is expected to put this instruction back before continuing the
438program.
439.It Fa dd_cc
440A pointer to the linked list of run-time allocated symbols that the debugger
441may be interested in.
442.El
443.Pp
444The
445.Em ld_entry
446structure defines a set of service routines within ld.so. See
447.Xr dlfcn 3
448for more information.
449.Bd -literal -offset indent
450struct ld_entry {
451	void	*(*dlopen)(char *, int);
452	int	(*dlclose)(void *);
453	void	*(*dlsym)(void *, char *);
454	int	(*dlctl)(void *, int, void *);
455	void	(*dlexit) __P((void));
456};
457.Ed
458
459The
460.Fa crt_ldso
461structure defines the interface between ld.so and the start-up code in crt0.
462.Bd -literal -offset indent
463struct crt_ldso {
464	int		crt_ba;
465	int		crt_dzfd;
466	int		crt_ldfd;
467	struct _dynamic	*crt_dp;
468	char		**crt_ep;
469	caddr_t		crt_bp;
470	char		*crt_prog;
471	char		*crt_ldso;
472	char		*crt_ldentry;
473};
474#define CRT_VERSION_SUN		1
475#define CRT_VERSION_BSD2	2
476#define CRT_VERSION_BSD3	3
477#define CRT_VERSION_BSD4	4
478.Ed
479.Bl -tag -width crt_dzfd
480.It Fa crt_ba
481The virtual address at which ld.so was loaded by crt0.
482.It Fa crt_dzfd
483On
484.Tn SunOS
485systems, this field contains an open file descriptor to
486.Dq /dev/zero
487used to get demand paged zeroed pages. On
488.Nx
489systems it contains -1.
490.It Fa crt_ldfd
491Contains an open file descriptor that was used by crt0 to load ld.so.
492.It Fa crt_dp
493A pointer to main's
494.Fa _dynamic
495structure.
496.It Fa crt_ep
497A pointer to the environment strings.
498.It Fa crt_bp
499The address at which a breakpoint will be placed by the run-time linker
500if the main program is run by a debugger.
501See
502.Fa so_debug
503.It Fa crt_prog
504The name of the main program as determined by crt0 (CRT_VERSION_BSD3 only).
505.It Fa crt_ldso
506The path of the run-time linker as mapped by crt0 (CRT_VERSION_BSD4 only).
507.It Fa crt_ldentry
508The
509.Xr dlfcn 3
510entry points provided by the run-time linker (CRT_VERSION_BSD4 only).
511.El
512.Pp
513The
514.Fa hints_header
515and
516.Fa hints_bucket
517structures define the layout of the library hints, normally found in
518.Dq /var/run/ld.so.hints,
519which is used by ld.so to quickly locate the shared object images in the
520filesystem.
521The organization of the hints file is not unlike that of an
522.Dq a.out
523object file, in that it contains a header determining the offset and size
524of a table of fixed sized hash buckets and a common string pool.
525.Bd -literal -offset indent
526struct hints_header {
527	long		hh_magic;
528#define HH_MAGIC	011421044151
529	long		hh_version;
530#define LD_HINTS_VERSION_1	1
531#define LD_HINTS_VERSION_2	2
532	long		hh_hashtab;
533	long		hh_nbucket;
534	long		hh_strtab;
535	long		hh_strtab_sz;
536	long		hh_ehints;
537	long		hh_dirlist;
538};
539.Ed
540.Bl -tag -width hh_strtab_sz
541.It Fa hh_magic
542Hints file magic number.
543.It Fa hh_version
544Interface version number.
545.It Fa hh_hashtab
546Offset of hash table.
547.It Fa hh_strtab
548Offset of string table.
549.It Fa hh_strtab_sz
550Size of strings.
551.It Fa hh_ehints
552Maximum usable offset in hints file.
553.It Fa hh_dirlist
554Offset in string table of a colon-separated list of directories that was
555used in constructing the hints file. See also
556.Xr ldconfig 8 .
557This field is only available with interface version number
558.Dv LD_HINTS_VERSION_2
559and higher.
560.El
561.Pp
562.Bd -literal -offset indent
563/*
564 * Hash table element in hints file.
565 */
566struct hints_bucket {
567	int		hi_namex;
568	int		hi_pathx;
569	int		hi_dewey[MAXDEWEY];
570	int		hi_ndewey;
571#define hi_major hi_dewey[0]
572#define hi_minor hi_dewey[1]
573	int		hi_next;
574};
575.Ed
576.Bl -tag -width hi_ndewey
577.It Fa hi_namex
578Index of the string identifying the library.
579.It Fa hi_pathx
580Index of the string representing the full path name of the library.
581.It Fa hi_dewey
582The version numbers of the shared library.
583.It Fa hi_ndewey
584The number of valid entries in
585.Fa hi_dewey .
586.It Fa hi_next
587Next bucket in case of hashing collisions.
588.El
589
590.Sh CAVEATS
591Only the (GNU) C compiler currently supports the creation of shared libraries.
592Other programming languages can not be used.
593
594