]> git.ipfire.org Git - thirdparty/man-pages.git/blame - man3/dladdr.3
fanotify_init.2, fanotify.7: Document FAN_REPORT_TID
[thirdparty/man-pages.git] / man3 / dladdr.3
CommitLineData
affaa041
MK
1'\" t
2.\" Copyright (C) 2015 Michael Kerrisk <mtk.manpages@gmail.com>
3.\" and Copyright (C) 2008 Petr Baudis <pasky@suse.cz> (dladdr caveat)
4.\"
5.\" %%%LICENSE_START(VERBATIM)
6.\" Permission is granted to make and distribute verbatim copies of this
7.\" manual provided the copyright notice and this permission notice are
8.\" preserved on all copies.
9.\"
10.\" Permission is granted to copy and distribute modified versions of this
11.\" manual under the conditions for verbatim copying, provided that the
12.\" entire resulting derived work is distributed under the terms of a
13.\" permission notice identical to this one.
14.\"
15.\" Since the Linux kernel and libraries are constantly changing, this
16.\" manual page may be incorrect or out-of-date. The author(s) assume no
17.\" responsibility for errors or omissions, or for damages resulting from
18.\" the use of the information contained herein. The author(s) may not
19.\" have taken the same level of care in the production of this manual,
20.\" which is licensed free of charge, as they might when working
21.\" professionally.
22.\"
23.\" Formatted or processed versions of this manual, if unaccompanied by
24.\" the source, must acknowledge the copyright and authors of this work.
25.\" %%%LICENSE_END
26.\"
4b8c67d9 27.TH DLADDR 3 2017-09-15 "Linux" "Linux Programmer's Manual"
affaa041
MK
28.SH NAME
29dladdr, dladdr1 \- translate address to symbolic information
30.SH SYNOPSIS
31.nf
32.B #define _GNU_SOURCE
33.B #include <dlfcn.h>
dbfe9c70 34.PP
affaa041 35.BI "int dladdr(void *" addr ", Dl_info *" info );
dbfe9c70 36.PP
affaa041
MK
37.BI "int dladdr1(void *" addr ", Dl_info *" info ", void **" \
38 extra_info ", int " flags );
dbfe9c70 39.PP
affaa041
MK
40Link with \fI\-ldl\fP.
41.fi
42.SH DESCRIPTION
43The function
44.BR dladdr ()
45determines whether the address specified in
46.IR addr
47is located in one of the shared objects loaded by the calling application.
48If it is, then
49.BR dladdr ()
50returns information about the shared object and symbol that overlaps
51.IR addr .
52This information is returned in a
53.I Dl_info
54structure:
51f5698d 55.PP
affaa041 56.in +4n
b8302363 57.EX
affaa041
MK
58typedef struct {
59 const char *dli_fname; /* Pathname of shared object that
60 contains address */
61 void *dli_fbase; /* Base address at which shared
62 object is loaded */
63 const char *dli_sname; /* Name of symbol whose definition
64 overlaps \fIaddr\fP */
65 void *dli_saddr; /* Exact address of symbol named
66 in \fIdli_sname\fP */
67} Dl_info;
b8302363 68.EE
affaa041
MK
69.in
70.PP
71If no symbol matching
72.I addr
73could be found, then
74.I dli_sname
75and
76.I dli_saddr
77are set to NULL.
847e0d88 78.PP
affaa041
MK
79The function
80.BR dladdr1 ()
81is like
82.BR dladdr (),
83but returns additional information via the argument
84.IR extra_info .
85The information returned depends on the value specified in
86.IR flags ,
87which can have one of the following values:
88.TP
89.B RTLD_DL_LINKMAP
10b22cd9 90Obtain a pointer to the link map for the matched file.
affaa041
MK
91The
92.IR extra_info
93argument points to a pointer to a
94.I link_map
95structure (i.e.,
96.IR "struct link_map\ **" ),
97defined in
98.I <link.h>
99as:
847e0d88 100.IP
affaa041 101.in +4n
b8302363 102.EX
affaa041
MK
103struct link_map {
104 ElfW(Addr) l_addr; /* Difference between the
105 address in the ELF file and
106 the address in memory */
107 char *l_name; /* Absolute pathname where
108 object was found */
109 ElfW(Dyn) *l_ld; /* Dynamic section of the
110 shared object */
111 struct link_map *l_next, *l_prev;
112 /* Chain of loaded objects */
113
114 /* Plus additional fields private to the
115 implementation */
116};
b8302363 117.EE
affaa041
MK
118.in
119.TP
120.B RTLD_DL_SYMENT
10b22cd9 121Obtain a pointer to the ELF symbol table entry of the matching symbol.
affaa041
MK
122The
123.IR extra_info
124argument is a pointer to a symbol pointer:
125.IR "const ElfW(Sym) **" .
126The
127.IR ElfW ()
128macro definition turns its argument into the name of an ELF data
129type suitable for the hardware architecture.
130For example, on a 64-bit platform,
131.I ElfW(Sym)
132yields the data type name
133.IR Elf64_Sym ,
134which is defined in
135.IR <elf.h>
136as:
847e0d88 137.IP
affaa041 138.in +4n
b8302363 139.EX
30ea59e7 140typedef struct {
affaa041
MK
141 Elf64_Word st_name; /* Symbol name */
142 unsigned char st_info; /* Symbol type and binding */
143 unsigned char st_other; /* Symbol visibility */
144 Elf64_Section st_shndx; /* Section index */
145 Elf64_Addr st_value; /* Symbol value */
146 Elf64_Xword st_size; /* Symbol size */
147} Elf64_Sym;
b8302363 148.EE
affaa041 149.in
847e0d88 150.IP
affaa041
MK
151The
152.I st_name
153field is an index into the string table.
847e0d88 154.IP
affaa041
MK
155The
156.I st_info
157field encodes the symbol's type and binding.
158The type can be extracted using the macro
159.BR ELF64_ST_TYPE(st_info)
160(or
161.BR ELF32_ST_TYPE()
162on 32-bit platforms), which yields one of the following values:
163.in +4n
164.TS
165lb lb
166lb l.
167Value Description
168STT_NOTYPE Symbol type is unspecified
169STT_OBJECT Symbol is a data object
170STT_FUNC Symbol is a code object
171STT_SECTION Symbol associated with a section
172STT_FILE Symbol's name is file name
173STT_COMMON Symbol is a common data object
174STT_TLS Symbol is thread-local data object
175STT_GNU_IFUNC Symbol is indirect code object
176.TE
177.in
178.IP
179The symbol binding can be extracted from the
180.I st_info
181field using the macro
182.BR ELF64_ST_BIND(st_info)
183(or
184.BR ELF32_ST_BIND()
185on 32-bit platforms), which yields one of the following values:
affaa041
MK
186.in +4n
187.TS
188lb lb
189lb l.
190Value Description
191STB_LOCAL Local symbol
192STB_GLOBAL Global symbol
193STB_WEAK Weak symbol
194STB_GNU_UNIQUE Unique symbol
195.TE
196.in
197.IP
198The
199.I st_other
200field contains the symbol's visibility, which can be extracted using the macro
201.BR ELF64_ST_VISIBILITY(st_info)
202(or
203.BR ELF32_ST_VISIBILITY()
204on 32-bit platforms), which yields one of the following values:
205.in +4n
206.TS
207lb lb
208lb l.
209Value Description
210STV_DEFAULT Default symbol visibility rules
211STV_INTERNAL Processor-specific hidden class
212STV_HIDDEN Symbol unavailable in other modules
213STV_PROTECTED Not preemptible, not exported
214.TE
215.in
216.SH RETURN VALUE
217On success, these functions return a nonzero value.
218If the address specified in
219.I addr
220could be matched to a shared object,
221but not to a symbol in the shared object, then the
222.I info->dli_sname
223and
224.I info->dli_saddr
225fields are set to NULL.
847e0d88 226.PP
affaa041
MK
227If the address specified in
228.I addr
229could not be matched to a shared object, then these functions return 0.
230In this case, an error message is
231.I not
232.\" According to the FreeBSD man page, dladdr1() does signal an
233.\" error via dlerror() for this case.
234available via
235.BR dlerror (3).
236.SH VERSIONS
237.BR dladdr ()
238is present in glibc 2.0 and later.
239.BR dladdr1 ()
240first appeared in glibc 2.3.3.
06c0008d
ZL
241.SH ATTRIBUTES
242For an explanation of the terms used in this section, see
243.BR attributes (7).
244.TS
245allbox;
246lbw19 lb lb
247l l l.
248Interface Attribute Value
249T{
250.BR dladdr (),
251.BR dladdr1 ()
252T} Thread safety MT-Safe
253.TE
affaa041
MK
254.SH CONFORMING TO
255These functions are nonstandard GNU extensions
256that are also present on Solaris.
257.SH BUGS
258Sometimes, the function pointers you pass to
259.BR dladdr ()
260may surprise you.
9ea5bc66 261On some architectures (notably i386 and x86-64),
affaa041
MK
262.I dli_fname
263and
264.I dli_fbase
265may end up pointing back at the object from which you called
266.BR dladdr (),
267even if the function used as an argument should come from
268a dynamically linked library.
269.PP
270The problem is that the function pointer will still be resolved
271at compile time, but merely point to the
272.I plt
273(Procedure Linkage Table)
274section of the original object (which dispatches the call after
275asking the dynamic linker to resolve the symbol).
276To work around this,
277you can try to compile the code to be position-independent:
278then, the compiler cannot prepare the pointer
ce65f81e 279at compile time any more and
affaa041
MK
280.BR gcc (1)
281will generate code that just loads the final symbol address from the
282.I got
283(Global Offset Table) at run time before passing it to
284.BR dladdr ().
285.SH SEE ALSO
286.BR dl_iterate_phdr (3),
9987012c 287.BR dlinfo (3),
affaa041 288.BR dlopen (3),
de7d051d 289.BR dlsym (3),
affaa041 290.BR ld.so (8)