---
name: "dladdr"
section: "3"
platform: "freebsd"
package: "base"
version: "16.0-CURRENT-20261027-61c70dc16a79"
release: "FreeBSD 16.0-CURRENT (2026-10-27)"
platforms: ["linux", "freebsd"]
url: "https://new.carta.tech/dladdr"
---

# dladdr(3)

find the shared object containing a given address

## NAME

**dladdr** – find the shared object containing a given address

## LIBRARY

Standard C Library (libc, -lc)

## SYNOPSIS

**#include \<dlfcn.h\>**

*int*\

**dladdr**(*const void \*addr*, *Dl\_info \*info*);

## DESCRIPTION

The **dladdr**() function queries the dynamic linker for information about the shared object containing the address *addr*. The information is returned in the structure specified by *info*. The structure contains at least the following members:

- const char \*dli\_fname

  The pathname of the shared object containing the address.

- void \*dli\_fbase

  The base address at which the shared object is mapped into the address space of the calling process.

- const char \*dli\_sname

  The name of the nearest run-time symbol with a value less than or equal to *addr*. When possible, the symbol name is returned as it would appear in C source code.

  If no symbol with a suitable value is found, both this field and *dli\_saddr* are set to NULL.

- void \*dli\_saddr

  The value of the symbol returned in dli\_sname.

The **dladdr**() function is available only in dynamically linked programs.

## ERRORS

If a mapped shared object containing *addr* cannot be found, **dladdr**() returns 0. In that case, a message detailing the failure can be retrieved by calling **dlerror**().

On success, a non-zero value is returned.

## SEE ALSO

[rtld(1)](/rtld/1.md), [dlopen(3)](/dlopen/3.md)

## HISTORY

The **dladdr**() function first appeared in the Solaris operating system.

## BUGS

This implementation is bug-compatible with the Solaris implementation. In particular, the following bugs are present:

- If *addr* lies in the main executable rather than in a shared library, the pathname returned in *dli\_fname* may not be correct. The pathname is taken directly from *argv\[0\]* of the calling process. When executing a program specified by its full pathname, most shells set *argv\[0\]* to the pathname. But this is not required of shells or guaranteed by the operating system.

- If *addr* is of the form *&func*, where *func* is a global function, its value may be an unpleasant surprise. In dynamically linked programs, the address of a global function is considered to point to its program linkage table entry, rather than to the entry point of the function itself. This causes most global functions to appear to be defined within the main executable, rather than in the shared libraries where the actual code resides.

- Returning 0 as an indication of failure goes against long-standing Unix tradition.