xref: /freebsd/lib/libc/gen/dlopen.3 (revision 4bc52338)
1.\" This source code is a product of Sun Microsystems, Inc. and is provided
2.\" for unrestricted use provided that this legend is included on all tape
3.\" media and as a part of the software program in whole or part.  Users
4.\" may copy or modify this source code without charge, but are not authorized
5.\" to license or distribute it to anyone else except as part of a product or
6.\" program developed by the user.
7.\"
8.\" THIS PROGRAM CONTAINS SOURCE CODE COPYRIGHTED BY SUN MICROSYSTEMS, INC.
9.\" SUN MICROSYSTEMS, INC., MAKES NO REPRESENTATIONS ABOUT THE SUITABLITY
10.\" OF SUCH SOURCE CODE FOR ANY PURPOSE.  IT IS PROVIDED "AS IS" WITHOUT
11.\" EXPRESS OR IMPLIED WARRANTY OF ANY KIND.  SUN MICROSYSTEMS, INC. DISCLAIMS
12.\" ALL WARRANTIES WITH REGARD TO SUCH SOURCE CODE, INCLUDING ALL IMPLIED
13.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN
14.\" NO EVENT SHALL SUN MICROSYSTEMS, INC. BE LIABLE FOR ANY SPECIAL, INDIRECT,
15.\" INCIDENTAL, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
16.\" FROM USE OF SUCH SOURCE CODE, REGARDLESS OF THE THEORY OF LIABILITY.
17.\"
18.\" This source code is provided with no support and without any obligation on
19.\" the part of Sun Microsystems, Inc. to assist in its use, correction,
20.\" modification or enhancement.
21.\"
22.\" SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
23.\" INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS
24.\" SOURCE CODE OR ANY PART THEREOF.
25.\"
26.\" Sun Microsystems, Inc.
27.\" 2550 Garcia Avenue
28.\" Mountain View, California 94043
29.\"
30.\" Copyright (c) 1991 Sun Microsystems, Inc.
31.\"
32.\" @(#) dlopen.3 1.6 90/01/31 SMI
33.\" $FreeBSD$
34.\"
35.Dd January 2, 2019
36.Dt DLOPEN 3
37.Os
38.Sh NAME
39.Nm dlopen ,
40.Nm fdlopen ,
41.Nm dlsym ,
42.Nm dlvsym ,
43.Nm dlfunc ,
44.Nm dlerror ,
45.Nm dlclose
46.Nd programmatic interface to the dynamic linker
47.Sh LIBRARY
48.Lb libc
49.Sh SYNOPSIS
50.In dlfcn.h
51.Ft void *
52.Fn dlopen "const char *path" "int mode"
53.Ft void *
54.Fn fdlopen "int fd" "int mode"
55.Ft void *
56.Fn dlsym "void * restrict handle" "const char * restrict symbol"
57.Ft void *
58.Fn dlvsym "void * restrict handle" "const char * restrict symbol" "const char * restrict version"
59.Ft dlfunc_t
60.Fn dlfunc "void * restrict handle" "const char * restrict symbol"
61.Ft char *
62.Fn dlerror "void"
63.Ft int
64.Fn dlclose "void *handle"
65.Sh DESCRIPTION
66These functions provide a simple programmatic interface to the services of the
67dynamic linker.
68Operations are provided to add new shared objects to a
69program's address space, to obtain the address bindings of symbols
70defined by such
71objects, and to remove such objects when their use is no longer required.
72.Pp
73The
74.Fn dlopen
75function
76provides access to the shared object in
77.Fa path ,
78returning a descriptor that can be used for later
79references to the object in calls to
80.Fn dlsym ,
81.Fn dlvsym
82and
83.Fn dlclose .
84If
85.Fa path
86was not in the address space prior to the call to
87.Fn dlopen ,
88it is placed in the address space.
89When an object is first loaded into the address space in this way, its
90function
91.Fn _init ,
92if any, is called by the dynamic linker.
93If
94.Fa path
95has already been placed in the address space in a previous call to
96.Fn dlopen ,
97it is not added a second time, although a reference count of
98.Fn dlopen
99operations on
100.Fa path
101is maintained.
102A null pointer supplied for
103.Fa path
104is interpreted as a reference to the main
105executable of the process.
106The
107.Fa mode
108argument
109controls the way in which external function references from the
110loaded object are bound to their referents.
111It must contain one of the following values, possibly ORed with
112additional flags which will be described subsequently:
113.Bl -tag -width RTLD_LAZYX
114.It Dv RTLD_LAZY
115Each external function reference is resolved when the function is first
116called.
117.It Dv RTLD_NOW
118All external function references are bound immediately by
119.Fn dlopen .
120.El
121.Pp
122.Dv RTLD_LAZY
123is normally preferred, for reasons of efficiency.
124However,
125.Dv RTLD_NOW
126is useful to ensure that any undefined symbols are discovered during the
127call to
128.Fn dlopen .
129.Pp
130One of the following flags may be ORed into the
131.Fa mode
132argument:
133.Bl -tag -width RTLD_NODELETE
134.It Dv RTLD_GLOBAL
135Symbols from this shared object and its directed acyclic graph (DAG)
136of needed objects will be available for resolving undefined references
137from all other shared objects.
138.It Dv RTLD_LOCAL
139Symbols in this shared object and its DAG of needed objects will be
140available for resolving undefined references only from other objects
141in the same DAG.
142This is the default, but it may be specified
143explicitly with this flag.
144.It Dv RTLD_TRACE
145When set, causes dynamic linker to exit after loading all objects
146needed by this shared object and printing a summary which includes
147the absolute pathnames of all objects, to standard output.
148With this flag
149.Fn dlopen
150will return to the caller only in the case of error.
151.It Dv RTLD_NODELETE
152Prevents unload of the loaded object on
153.Fn dlclose .
154The same behaviour may be requested by
155.Fl "z nodelete"
156option of the static linker
157.Xr ld 1 .
158.It Dv RTLD_NOLOAD
159Only return valid handle for the object if it is already loaded in
160the process address space, otherwise
161.Dv NULL
162is returned.
163Other mode flags may be specified, which will be applied for promotion
164for the found object.
165.El
166.Pp
167If
168.Fn dlopen
169fails, it returns a null pointer, and sets an error condition which may
170be interrogated with
171.Fn dlerror .
172.Pp
173The
174.Fn fdlopen
175function is similar to
176.Fn dlopen ,
177but it takes the file descriptor argument
178.Fa fd ,
179which is used for the file operations needed to load an object
180into the address space.
181The file descriptor
182.Fa fd
183is not closed by the function regardless a result of execution,
184but a duplicate of the file descriptor is.
185This may be important if a
186.Xr lockf 3
187lock is held on the passed descriptor.
188The
189.Fa fd
190argument -1 is interpreted as a reference to the main
191executable of the process, similar to
192.Va NULL
193value for the
194.Fa name
195argument to
196.Fn dlopen .
197The
198.Fn fdlopen
199function can be used by the code that needs to perform
200additional checks on the loaded objects, to prevent races with
201symlinking or renames.
202.Pp
203The
204.Fn dlsym
205function
206returns the address binding of the symbol described in the null-terminated
207character string
208.Fa symbol ,
209as it occurs in the shared object identified by
210.Fa handle .
211The symbols exported by objects added to the address space by
212.Fn dlopen
213can be accessed only through calls to
214.Fn dlsym .
215Such symbols do not supersede any definition of those symbols already present
216in the address space when the object is loaded, nor are they available to
217satisfy normal dynamic linking references.
218.Pp
219If
220.Fn dlsym
221is called with the special
222.Fa handle
223.Dv NULL ,
224it is interpreted as a reference to the executable or shared object
225from which the call
226is being made.
227Thus a shared object can reference its own symbols.
228.Pp
229If
230.Fn dlsym
231is called with the special
232.Fa handle
233.Dv RTLD_DEFAULT ,
234the search for the symbol follows the algorithm used for resolving
235undefined symbols when objects are loaded.
236The objects searched are
237as follows, in the given order:
238.Bl -enum
239.It
240The referencing object itself (or the object from which the call to
241.Fn dlsym
242is made), if that object was linked using the
243.Fl Bsymbolic
244option to
245.Xr ld 1 .
246.It
247All objects loaded at program start-up.
248.It
249All objects loaded via
250.Fn dlopen
251with the
252.Dv RTLD_GLOBAL
253flag set in the
254.Fa mode
255argument.
256.It
257All objects loaded via
258.Fn dlopen
259which are in needed-object DAGs that also contain the referencing object.
260.El
261.Pp
262If
263.Fn dlsym
264is called with the special
265.Fa handle
266.Dv RTLD_NEXT ,
267then the search for the symbol is limited to the shared objects
268which were loaded after the one issuing the call to
269.Fn dlsym .
270Thus, if the function is called from the main program, all
271the shared libraries are searched.
272If it is called from a shared library, all subsequent shared
273libraries are searched.
274.Dv RTLD_NEXT
275is useful for implementing wrappers around library functions.
276For example, a wrapper function
277.Fn getpid
278could access the
279.Dq real
280.Fn getpid
281with
282.Li dlsym(RTLD_NEXT, \&"getpid\&") .
283(Actually, the
284.Fn dlfunc
285interface, below, should be used, since
286.Fn getpid
287is a function and not a data object.)
288.Pp
289If
290.Fn dlsym
291is called with the special
292.Fa handle
293.Dv RTLD_SELF ,
294then the search for the symbol is limited to the shared object
295issuing the call to
296.Fn dlsym
297and those shared objects which were loaded after it.
298.Pp
299The
300.Fn dlsym
301function
302returns a null pointer if the symbol cannot be found, and sets an error
303condition which may be queried with
304.Fn dlerror .
305.Pp
306The
307.Fn dlvsym
308function behaves like
309.Fn dlsym ,
310but takes an extra argument
311.Fa version :
312a null-terminated character string which is used to request a specific version
313of
314.Fa symbol .
315.Pp
316The
317.Fn dlfunc
318function
319implements all of the behavior of
320.Fn dlsym ,
321but has a return type which can be cast to a function pointer without
322triggering compiler diagnostics.
323(The
324.Fn dlsym
325function
326returns a data pointer; in the C standard, conversions between
327data and function pointer types are undefined.
328Some compilers and
329.Xr lint 1
330utilities warn about such casts.)
331The precise return type of
332.Fn dlfunc
333is unspecified; applications must cast it to an appropriate function pointer
334type.
335.Pp
336The
337.Fn dlerror
338function
339returns a null-terminated character string describing the last error that
340occurred during a call to
341.Fn dlopen ,
342.Fn dladdr ,
343.Fn dlinfo ,
344.Fn dlsym ,
345.Fn dlvsym ,
346.Fn dlfunc ,
347or
348.Fn dlclose .
349If no such error has occurred,
350.Fn dlerror
351returns a null pointer.
352At each call to
353.Fn dlerror ,
354the error indication is reset.
355Thus in the case of two calls
356to
357.Fn dlerror ,
358where the second call follows the first immediately, the second call
359will always return a null pointer.
360.Pp
361The
362.Fn dlclose
363function
364deletes a reference to the shared object referenced by
365.Fa handle .
366If the reference count drops to 0, the object is removed from the
367address space, and
368.Fa handle
369is rendered invalid.
370Just before removing a shared object in this way, the dynamic linker
371calls the object's
372.Fn _fini
373function, if such a function is defined by the object.
374If
375.Fn dlclose
376is successful, it returns a value of 0.
377Otherwise it returns -1, and sets an error condition that can be
378interrogated with
379.Fn dlerror .
380.Pp
381The object-intrinsic functions
382.Fn _init
383and
384.Fn _fini
385are called with no arguments, and are not expected to return values.
386.Sh NOTES
387ELF executables need to be linked
388using the
389.Fl export-dynamic
390option to
391.Xr ld 1
392for symbols defined in the executable to become visible to
393.Fn dlsym ,
394.Fn dlvsym
395or
396.Fn dlfunc
397.Pp
398Other ELF platforms require linking with
399.Lb libdl
400to provide
401.Fn dlopen
402and other functions.
403.Fx
404does not require linking with the library, but supports it for compatibility.
405.Pp
406In previous implementations, it was necessary to prepend an underscore
407to all external symbols in order to gain symbol
408compatibility with object code compiled from the C language.
409This is
410still the case when using the (obsolete)
411.Fl aout
412option to the C language compiler.
413.Sh ERRORS
414The
415.Fn dlopen ,
416.Fn fdlopen ,
417.Fn dlsym ,
418.Fn dlvsym ,
419and
420.Fn dlfunc
421functions
422return a null pointer in the event of errors.
423The
424.Fn dlclose
425function
426returns 0 on success, or -1 if an error occurred.
427Whenever an error has been detected, a message detailing it can be
428retrieved via a call to
429.Fn dlerror .
430.Sh SEE ALSO
431.Xr ld 1 ,
432.Xr rtld 1 ,
433.Xr dladdr 3 ,
434.Xr dlinfo 3 ,
435.Xr link 5
436