xref: /dragonfly/lib/libc/gen/dladdr.3 (revision 9348a738)
1.\"
2.\" Copyright (c) 1998 John D. Polstra
3.\" All rights reserved.
4.\"
5.\" Redistribution and use in source and binary forms, with or without
6.\" modification, are permitted provided that the following conditions
7.\" are met:
8.\" 1. Redistributions of source code must retain the above copyright
9.\"    notice, this list of conditions and the following disclaimer.
10.\" 2. Redistributions in binary form must reproduce the above copyright
11.\"    notice, this list of conditions and the following disclaimer in the
12.\"    documentation and/or other materials provided with the distribution.
13.\"
14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
17.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
24.\" SUCH DAMAGE.
25.\"
26.\" $FreeBSD: head/lib/libc/gen/dladdr.3 206622 2010-04-14 19:08:06Z uqs $
27.\"
28.Dd April 28, 2011
29.Dt DLADDR 3
30.Os
31.Sh NAME
32.Nm dladdr
33.Nd find the shared object containing a given address
34.Sh LIBRARY
35This function is not in a library.
36It is included in every dynamically linked program automatically.
37.Sh SYNOPSIS
38.In dlfcn.h
39.Ft int
40.Fn dladdr "const void * __restrict addr" "Dl_info * __restrict dlip"
41.Sh DESCRIPTION
42The
43.Fn dladdr
44function
45queries the dynamic linker for information about the shared object
46containing the address
47.Fa addr .
48The information is returned in the structure specified by
49.Fa info .
50The structure contains at least the following members:
51.Bl -tag -width "XXXconst char *dli_fname"
52.It Li "const char *dli_fname"
53The pathname of the shared object containing the address.
54.It Li "void *dli_fbase"
55The base address at which the shared object is mapped into the
56address space of the calling process.
57.It Li "const char *dli_sname"
58The name of the nearest run-time symbol with a value less than or
59equal to
60.Fa addr .
61When possible, the symbol name is returned as it would appear in C
62source code.
63.Pp
64If no symbol with a suitable value is found, both this field and
65.Va dli_saddr
66are set to
67.Dv NULL .
68.It Li "void *dli_saddr"
69The value of the symbol returned in
70.Li dli_sname .
71.El
72.Pp
73The
74.Fn dladdr
75function
76is available only in dynamically linked programs.
77.Sh ERRORS
78If a mapped shared object containing
79.Fa addr
80cannot be found,
81.Fn dladdr
82returns 0.
83In that case, a message detailing the failure can be retrieved by
84calling
85.Fn dlerror .
86.Pp
87On success, a non-zero value is returned.
88.Sh SEE ALSO
89.Xr rtld 1 ,
90.Xr dlfcn 3
91.Sh HISTORY
92The
93.Fn dladdr
94function first appeared in the Solaris operating system.
95.Sh BUGS
96This implementation is bug-compatible with the Solaris
97implementation.
98In particular, the following bugs are present:
99.Bl -bullet
100.It
101If
102.Fa addr
103lies in the main executable rather than in a shared library, the
104pathname returned in
105.Va dli_fname
106may not be correct.
107The pathname is taken directly from
108.Va argv[0]
109of the calling process.
110When executing a program specified by its
111full pathname, most shells set
112.Va argv[0]
113to the pathname.
114But this is not required of shells or guaranteed
115by the operating system.
116.It
117If
118.Fa addr
119is of the form
120.Va &func ,
121where
122.Va func
123is a global function, its value may be an unpleasant surprise.
124In
125dynamically linked programs, the address of a global function is
126considered to point to its program linkage table entry, rather than to
127the entry point of the function itself.
128This causes most global
129functions to appear to be defined within the main executable, rather
130than in the shared libraries where the actual code resides.
131.It
132Returning 0 as an indication of failure goes against long-standing
133Unix tradition.
134.El
135