from small one page howto to huge articles all in one place
 

search text in:





Poll
Which linux distribution do you use?







poll results

Last additions:
using iotop to find disk usage hogs

using iotop to find disk usage hogs

words:

887

views:

194568

userrating:

average rating: 1.7 (102 votes) (1=very good 6=terrible)


May 25th. 2007:
Words

486

Views

251893

why adblockers are bad


Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

words:

161

views:

140714

userrating:

average rating: 1.4 (42 votes) (1=very good 6=terrible)


April, 26th. 2006:

Druckversion
You are here: manpages





DLADDR

Section: Linux Programmer's Manual (3)
Updated: 2017-09-15
Index Return to Main Contents
 

NAME

dladdr, dladdr1 - translate address to symbolic information  

SYNOPSIS

#define _GNU_SOURCE
#include <dlfcn.h>

int dladdr(void *addr, Dl_info *info);

int dladdr1(void *addr, Dl_info *info, void **extra_info, int flags);

Link with -ldl.
 

DESCRIPTION

The function dladdr() determines whether the address specified in addr is located in one of the shared objects loaded by the calling application. If it is, then dladdr() returns information about the shared object 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 information via the argument extra_info. The information returned depends on the value specified in flags, which can have one of the following values:

RTLD_DL_LINKMAP
Obtain a pointer to the link map for the matched file. The extra_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:
ValueDescription
STT_NOTYPESymbol type is unspecified
STT_OBJECTSymbol is a data object
STT_FUNCSymbol is a code object
STT_SECTIONSymbol associated with a section
STT_FILESymbol's name is file name
STT_COMMONSymbol is a common data object
STT_TLSSymbol is thread-local data object
STT_GNU_IFUNCSymbol 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:
ValueDescription
STB_LOCALLocal symbol
STB_GLOBALGlobal symbol
STB_WEAKWeak symbol
STB_GNU_UNIQUEUnique 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:
ValueDescription
STV_DEFAULTDefault symbol visibility rules
STV_INTERNALProcessor-specific hidden class
STV_HIDDENSymbol unavailable in other modules
STV_PROTECTEDNot 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 symbol 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 object, then these functions return 0. In this case, an error message is not available via dlerror(3).  

VERSIONS

dladdr() is present in glibc 2.0 and later. dladdr1() first appeared in glibc 2.3.3.  

ATTRIBUTES

For an explanation of the terms used in this section, see attributes(7).
InterfaceAttributeValue
dladdr(), dladdr1() Thread safetyMT-Safe
 

CONFORMING TO

These functions are nonstandard GNU extensions that are also present on 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 compile time, but merely point to the plt (Procedure Linkage Table) section of the original object (which dispatches the call after asking the dynamic linker to resolve the symbol). To work around this, you can try to compile the code to be position-independent: then, the compiler cannot prepare the pointer at compile time any more and gcc(1) will generate 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)  

COLOPHON

This page is part of release 4.13 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/.


 

Index

NAME
SYNOPSIS
DESCRIPTION
RETURN VALUE
VERSIONS
ATTRIBUTES
CONFORMING TO
BUGS
SEE ALSO
COLOPHON





Support us on Content Nation
rdf newsfeed | rss newsfeed | Atom newsfeed
- Powered by LeopardCMS - Running on Gentoo -
Copyright 2004-2020 Sascha Nitsch Unternehmensberatung GmbH
Valid XHTML1.1 : Valid CSS : buttonmaker
- Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 -
- Copyright and legal notices -
Time to create this page: 14.6 ms