dl_iterate_phdr(3)

โœจ dl_iterate_phdr โœจ โ€” it's a manual page, bestie (section 3, Library Functions Manual)

okay so picture this: you're a program, you've been loading shared objects all day, and now you wanna know which ones and in what order. enter dl_iterate_phdr, our girl. ๐Ÿ’…


๐ŸŒธ NAME ๐ŸŒธ

dl_iterate_phdr โ€” walk through list of shared objects

๐Ÿ“š LIBRARY ๐Ÿ“š

Standard C library (libc, -lc)

๐ŸŽ€ SYNOPSIS ๐ŸŽ€

#define _GNU_SOURCE         /* See feature_test_macros(7) */
#include <link.h>

int dl_iterate_phdr(
         typeof(int (struct dl_phdr_info *info, size_t size, void *data))
             *callback,
         void *data);

๐Ÿ’– DESCRIPTION ๐Ÿ’–

So dl_iterate_phdr() is literally the function that lets your app inquire at run time to find out which shared objects it has loaded, and the order in which they were loaded. no cap. ๐Ÿ”

What it does is walk through the list of an application's shared objects, and it calls the function callback once for each object โ€” until either all the shared objects have been processed, or callback returns a nonzero value. (yeah, bestie, you can bail out early by returning nonzero, that's the whole trick.)

Every single call to callback gets three arguments:

  • info โ€” a pointer to a structure containing information about the shared object
  • size โ€” the size of the structure pointed to by info
  • data โ€” a copy of whatever value was passed by the calling program as the second argument (also named data) in the call to dl_iterate_phdr()

The info argument is a structure of the following type:

struct dl_phdr_info {
    ElfW(Addr)        dlpi_addr;  /* Base address of object */
    const char       *dlpi_name;  /* (Null-terminated) name of
                                     object */
    const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
                                     ELF program headers
                                     for this object */
    ElfW(Half)        dlpi_phnum; /* # of items in dlpi_phdr */

    /* The following fields were added in glibc 2.4, after the first
       version of this structure was available.  Check the size
       argument passed to the dl_iterate_phdr callback to determine
       whether or not each later member is available.  */

    unsigned long long dlpi_adds;
                    /* Incremented when a new object may
                       have been added */
    unsigned long long dlpi_subs;
                    /* Incremented when an object may
                       have been removed */
    size_t dlpi_tls_modid;
                    /* If there is a PT_TLS segment, its module
                       ID as used in TLS relocations, else zero */
    void  *dlpi_tls_data;
                    /* The address of the calling thread's instance
                       of this module's PT_TLS segment, if it has
                       one and it has been allocated in the calling
                       thread, otherwise a null pointer */
};
okay quick detour, the ElfW() macro definition turns its argument into the name of an ELF data type suitable for the hardware architecture. for example, on a 32-bit platform, ElfW(Addr) yields the data type name Elf32_Addr. further information on these types can be found in the <elf.h> and <link.h> header files. iykyk. ๐Ÿงš

Now, the fields, one by one:

  • dlpi_addr โ€” indicates the base address of the shared object (i.e., the difference between the virtual memory address of the shared object and the offset of that object in the file from which it was loaded)
  • dlpi_name โ€” a null-terminated string giving the pathname from which the shared object was loaded

And to understand the meaning of the dlpi_phdr and dlpi_phnum fields, we need to be aware that an ELF shared object consists of a number of segments, each of which has a corresponding program header describing the segment. so:

  • dlpi_phdr โ€” a pointer to an array of the program headers for this shared object
  • dlpi_phnum โ€” indicates the size of this array

These program headers are structures of the following form:

typedef struct {
    Elf32_Word  p_type;    /* Segment type */
    Elf32_Off   p_offset;  /* Segment file offset */
    Elf32_Addr  p_vaddr;   /* Segment virtual address */
    Elf32_Addr  p_paddr;   /* Segment physical address */
    Elf32_Word  p_filesz;  /* Segment size in file */
    Elf32_Word  p_memsz;   /* Segment size in memory */
    Elf32_Word  p_flags;   /* Segment flags */
    Elf32_Word  p_align;   /* Segment alignment */
} Elf32_Phdr;

Note that we can calculate the location of a particular program header, x, in virtual memory using the formula:

addr == info->dlpi_addr + info->dlpi_phdr[x].p_vaddr;

Possible values for p_type include the following (see <elf.h> for further details):

#define PT_LOAD         1    /* Loadable program segment */
#define PT_DYNAMIC      2    /* Dynamic linking information */
#define PT_INTERP       3    /* Program interpreter */
#define PT_NOTE         4    /* Auxiliary information */
#define PT_SHLIB        5    /* Reserved */
#define PT_PHDR         6    /* Entry for header table itself */
#define PT_TLS          7    /* Thread-local storage segment */
#define PT_GNU_EH_FRAME 0x6474e550 /* GCC .eh_frame_hdr segment */
#define PT_GNU_STACK  0x6474e551 /* Indicates stack executability */
#define PT_GNU_RELRO  0x6474e552 /* Read-only after relocation */

๐Ÿซถ RETURN VALUE ๐Ÿซถ

The dl_iterate_phdr() function returns whatever value was returned by the last call to callback. that's it, that's the rule. ๐Ÿ’ซ

๐ŸŒˆ ATTRIBUTES ๐ŸŒˆ

For an explanation of the terms used in this section, see attributes(7).

  • Interface: dl_iterate_phdr()
  • Attribute: Thread safety
  • Value: MT-Safe

so yeah, she's MT-Safe, go wild (responsibly). โœจ

๐Ÿฆ‹ VERSIONS ๐Ÿฆ‹

Various other systems provide a version of this function, although details of the returned dl_phdr_info structure differ. On the BSDs and Solaris, the structure includes the fields dlpi_addr, dlpi_name, dlpi_phdr, and dlpi_phnum in addition to other implementation-specific fields.

Future versions of the C library may add further fields to the dl_phdr_info structure; in that event, the size argument provides a mechanism for the callback function to discover whether it is running on a system with added fields. (so likeโ€ฆ always check size, bestie. it's giving future-proof. ๐Ÿ”ฎ)

โญ STANDARDS โญ

None.

๐Ÿ‘‘ HISTORY ๐Ÿ‘‘

glibc 2.2.4.

๐Ÿ’œ NOTES ๐Ÿ’œ

The first object visited by callback is the main program. For the main program, the dlpi_name field will be an empty string.

so if you're staring at an empty dlpi_name like ๐Ÿ‘๏ธ๐Ÿ‘„๐Ÿ‘๏ธ โ€” congrats, that's the main program, not a bug.

๐ŸŽ€ EXAMPLES ๐ŸŽ€

Y'all ready? Here's a whole little program that spills the tea on every shared object it's loaded, bestie. For each shared object it prints a lil' info dump โ€” virtual address, size, flags, and type โ€” for each of that object's ELF segments. ๐Ÿ’…

And here's a real shell session showing what it spits out on an x86-64 system. Heads up: the very first shared object in the list, the one whose name is the empty string, is the main program itself. Not a bug, just how it is. โœจ

$ ./a.out;
Name: "" (9 segments)
     0: [      0x400040; memsz:    1f8] flags: 0x5; PT_PHDR
     1: [      0x400238; memsz:     1c] flags: 0x4; PT_INTERP
     2: [      0x400000; memsz:    ac4] flags: 0x5; PT_LOAD
     3: [      0x600e10; memsz:    240] flags: 0x6; PT_LOAD
     4: [      0x600e28; memsz:    1d0] flags: 0x6; PT_DYNAMIC
     5: [      0x400254; memsz:     44] flags: 0x4; PT_NOTE
     6: [      0x400970; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
     7: [         (nil); memsz:      0] flags: 0x6; PT_GNU_STACK
     8: [      0x600e10; memsz:    1f0] flags: 0x4; PT_GNU_RELRO
Name: "linux-vdso.so.1" (4 segments)
     0: [0x7ffc6edd1000; memsz:    e89] flags: 0x5; PT_LOAD
     1: [0x7ffc6edd1360; memsz:    110] flags: 0x4; PT_DYNAMIC
     2: [0x7ffc6edd17b0; memsz:     3c] flags: 0x4; PT_NOTE
     3: [0x7ffc6edd17ec; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
Name: "/lib64/libc.so.6" (10 segments)
     0: [0x7f55712ce040; memsz:    230] flags: 0x5; PT_PHDR
     1: [0x7f557145b980; memsz:     1c] flags: 0x4; PT_INTERP
     2: [0x7f55712ce000; memsz: 1b6a5c] flags: 0x5; PT_LOAD
     3: [0x7f55716857a0; memsz:   9240] flags: 0x6; PT_LOAD
     4: [0x7f5571688b80; memsz:    1f0] flags: 0x6; PT_DYNAMIC
     5: [0x7f55712ce270; memsz:     44] flags: 0x4; PT_NOTE
     6: [0x7f55716857a0; memsz:     78] flags: 0x4; PT_TLS
     7: [0x7f557145b99c; memsz:   544c] flags: 0x4; PT_GNU_EH_FRAME
     8: [0x7f55712ce000; memsz:      0] flags: 0x6; PT_GNU_STACK
     9: [0x7f55716857a0; memsz:   3860] flags: 0x4; PT_GNU_RELRO
Name: "/lib64/ld-linux-x86-64.so.2" (7 segments)
     0: [0x7f557168f000; memsz:  20828] flags: 0x5; PT_LOAD
     1: [0x7f55718afba0; memsz:   15a8] flags: 0x6; PT_LOAD
     2: [0x7f55718afe10; memsz:    190] flags: 0x6; PT_DYNAMIC
     3: [0x7f557168f1c8; memsz:     24] flags: 0x4; PT_NOTE
     4: [0x7f55716acec4; memsz:    604] flags: 0x4; PT_GNU_EH_FRAME
     5: [0x7f557168f000; memsz:      0] flags: 0x6; PT_GNU_STACK
     6: [0x7f55718afba0; memsz:    460] flags: 0x4; PT_GNU_RELRO

๐ŸŒธ Program source ๐ŸŒธ

Okay here's the actual source, verbatim, do not @ me, it's giving educational ๐Ÿ’–

#define _GNU_SOURCE
#include <link.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

static int
callback(struct dl_phdr_info *info, size_t size, void *data)
{
    char *type;
    int p_type;

    printf("Name: \"%s\" (%d segments)\n", info->dlpi_name,
           info->dlpi_phnum);

    for (size_t j = 0; j < info->dlpi_phnum; j++) {
        p_type = info->dlpi_phdr[j].p_type;
        type = (p_type == PT_LOAD) ? "PT_LOAD" :
               (p_type == PT_DYNAMIC) ? "PT_DYNAMIC" :
               (p_type == PT_INTERP) ? "PT_INTERP" :
               (p_type == PT_NOTE) ? "PT_NOTE" :
               (p_type == PT_INTERP) ? "PT_INTERP" :
               (p_type == PT_PHDR) ? "PT_PHDR" :
               (p_type == PT_TLS) ? "PT_TLS" :
               (p_type == PT_GNU_EH_FRAME) ? "PT_GNU_EH_FRAME" :
               (p_type == PT_GNU_STACK) ? "PT_GNU_STACK" :
               (p_type == PT_GNU_RELRO) ? "PT_GNU_RELRO" : NULL;

        printf("    %2zu: [%14p; memsz:%7jx] flags: %#jx; ", j,
               (void *) (info->dlpi_addr + info->dlpi_phdr[j].p_vaddr),
               (uintmax_t) info->dlpi_phdr[j].p_memsz,
               (uintmax_t) info->dlpi_phdr[j].p_flags);
        if (type != NULL)
            printf("%s\n", type);
        else
            printf("[other (%#x)]\n", p_type);
    }

    return 0;
}

int
main(void)
{
    dl_iterate_phdr(callback, NULL);

    exit(EXIT_SUCCESS);
}
Not me leaving that duplicated PT_INTERP ternary branch in thereโ€ฆ it's literally in the original, so it stays. Periooooodt. ๐Ÿ™ˆ

๐ŸŒˆ SEE ALSO ๐ŸŒˆ

Also, the Executable and Linking Format Specification โ€” you can find it floating around at various locations online. Go off, bestie. ๐Ÿ”ฅ


And that's a wrap, my love! ๐Ÿ’– This page is from Linux man-pages 6.20, dated 2026-02-08 โ€” that's the dl_iterate_phdr(3) tea, served fresh. Now go iterate some program headers, you absolute icon. ๐Ÿฆ‹๐Ÿ’…๐Ÿ‘‘

๐Ÿ“ฆ where this page comes from
  • arch rolling: man-pages 6.20-1 ยท BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
  • nixpkgs unstable: man-pages 6.20
  • ๐Ÿ“œ the page's license: Linux-man-pages-copyleft
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms