dladdr(3) Library Functions Manual dladdr(3)
NAME
dladdr, dladdr1 - translate address to symbolic information
LIBRARY
Dynamic linking library (libdl, -ldl)
SYNOPSIS
#define _GNU_SOURCE
#include <dlfcn.h>
int dladdr(const void *addr, Dl_info *info);
int dladdr1(const void *addr, Dl_info *info, void **extra_info,
int flags);
DESCRIPTION
The function dladdr() determines whether the address specified in addr
is located in one of the shared objects loaded by the calling applica-
tion. If it is, then dladdr() returns information about the shared ob-
ject and symbol that overlaps addr. This information is returned in a
Dl_info structure:
typedef struct {
const char *dli_fname; /* Pathname of shared object that
contains address */
void *dli_fbase; /* Base address at which shared
object is loaded */
const char *dli_sname; /* Name of symbol whose definition
overlaps addr */
void *dli_saddr; /* Exact address of symbol named
in dli_sname */
} Dl_info;
If no symbol matching addr could be found, then dli_sname and dli_saddr
are set to NULL.
The function dladdr1() is like dladdr(), but returns additional informa-
tion via the argument extra_info. The information returned depends on
the value specified in flags, which can have one of the following val-
ues:
RTLD_DL_LINKMAP
Obtain a pointer to the link map for the matched file. The ex-
tra_info argument points to a pointer to a link_map structure
(i.e., struct link_map **), defined in <link.h> as:
struct link_map {
ElfW(Addr) l_addr; /* Difference between the
address in the ELF file and
the address in memory */
char *l_name; /* Absolute pathname where
object was found */
ElfW(Dyn) *l_ld; /* Dynamic section of the
shared object */
struct link_map *l_next, *l_prev;
/* Chain of loaded objects */
/* Plus additional fields private to the
implementation */
};
RTLD_DL_SYMENT
Obtain a pointer to the ELF symbol table entry of the matching
symbol. The extra_info argument is a pointer to a symbol
pointer: const ElfW(Sym) **. The ElfW() macro definition turns
its argument into the name of an ELF data type suitable for the
hardware architecture. For example, on a 64-bit platform,
ElfW(Sym) yields the data type name Elf64_Sym, which is defined
in <elf.h> as:
typedef struct {
Elf64_Word st_name; /* Symbol name */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf64_Section st_shndx; /* Section index */
Elf64_Addr st_value; /* Symbol value */
Elf64_Xword st_size; /* Symbol size */
} Elf64_Sym;
The st_name field is an index into the string table.
The st_info field encodes the symbol's type and binding. The
type can be extracted using the macro ELF64_ST_TYPE(st_info) (or
ELF32_ST_TYPE() on 32-bit platforms), which yields one of the
following values:
Value Description
STT_NOTYPE Symbol type is unspecified
STT_OBJECT Symbol is a data object
STT_FUNC Symbol is a code object
STT_SECTION Symbol associated with a section
STT_FILE Symbol's name is filename
STT_COMMON Symbol is a common data object
STT_TLS Symbol is thread-local data object
STT_GNU_IFUNC Symbol is indirect code object
The symbol binding can be extracted from the st_info field using
the macro ELF64_ST_BIND(st_info) (or ELF32_ST_BIND() on 32-bit
platforms), which yields one of the following values:
Value Description
STB_LOCAL Local symbol
STB_GLOBAL Global symbol
STB_WEAK Weak symbol
STB_GNU_UNIQUE Unique symbol
The st_other field contains the symbol's visibility, which can be
extracted using the macro ELF64_ST_VISIBILITY(st_info) (or
ELF32_ST_VISIBILITY() on 32-bit platforms), which yields one of
the following values:
Value Description
STV_DEFAULT Default symbol visibility rules
STV_INTERNAL Processor-specific hidden class
STV_HIDDEN Symbol unavailable in other modules
STV_PROTECTED Not preemptible, not exported
RETURN VALUE
On success, these functions return a nonzero value. If the address
specified in addr could be matched to a shared object, but not to a sym-
bol in the shared object, then the info->dli_sname and info->dli_saddr
fields are set to NULL.
If the address specified in addr could not be matched to a shared ob-
ject, then these functions return 0. In this case, an error message is
not available via dlerror(3).
ATTRIBUTES
For an explanation of the terms used in this section, see attributes(7).
┌────────────────────────────────────────────┬───────────────┬─────────┐
│ Interface │ Attribute │ Value │
├────────────────────────────────────────────┼───────────────┼─────────┤
│ dladdr(), dladdr1() │ Thread safety │ MT-Safe │
└────────────────────────────────────────────┴───────────────┴─────────┘
STANDARDS
GNU.
HISTORY
dladdr()
glibc 2.0.
dladdr1()
glibc 2.3.3.
Solaris.
BUGS
Sometimes, the function pointers you pass to dladdr() may surprise you.
On some architectures (notably i386 and x86-64), dli_fname and dli_fbase
may end up pointing back at the object from which you called dladdr(),
even if the function used as an argument should come from a dynamically
linked library.
The problem is that the function pointer will still be resolved at com-
pile time, but merely point to the plt (Procedure Linkage Table) section
of the original object (which dispatches the call after asking the dy-
namic linker to resolve the symbol). To work around this, you can try
to compile the code to be position-independent: then, the compiler can-
not prepare the pointer at compile time any more and gcc(1) will gener-
ate code that just loads the final symbol address from the got (Global
Offset Table) at run time before passing it to dladdr().
SEE ALSO
dl_iterate_phdr(3), dlinfo(3), dlopen(3), dlsym(3), ld.so(8)
Linux man-pages 6.9.1 2024-05-02 dladdr(3)
Generated by dwww version 1.16 on Tue Dec 16 04:26:57 CET 2025.