The ELF Format & Binary Tools

Before ELF (Executable and Linkable Format), Unix systems used several incompatible binary formats — a.out on early Unix/Linux, COFF on System V, PE on Windows. Each had different ideas about how to represent sections, symbols, and relocations, which made cross-tool portability painful.

ELF was introduced with System V Release 4 (SVR4) in the late 1980s and was adopted by Linux early on. It has three related but distinct roles in one format:

1. Relocatable object file (.o): the output of the assembler/compiler for a single translation unit. Not yet executable — symbol references may be unresolved.
2. Executable file: produced by the linker. All symbols resolved, ready to execve().
3. Shared object (.so): a dynamic library. Partially resolved, completed at load time by the dynamic linker.

All three variants share the same basic structure. The key insight is that ELF is dual-view: the same bytes are interpreted through a section-header table (the linker's view, describing logical groupings) and a program-header table (the loader's view, describing what to map into memory). This duality is one of ELF's most important and most misunderstood aspects.

On a modern Linux system, ELF covers:

• x86-64, aarch64, riscv64, arm, mips, powerpc, and dozens more architectures.
• 32-bit (Elf32_*) and 64-bit (Elf64_*) variants.
• Little-endian and big-endian byte orders.

All of this is described in a single, stable ABI documented in the System V ABI supplement for each architecture.

# Confirm an ELF file with the 'magic bytes'
$ xxd /bin/ls | head -2
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
#         ^--- 0x7f 'E' 'L' 'F'  = magic
#                   ^^ 02 = 64-bit, 01 = little-endian, 01 = ELF version

# Check the ELF type
$ readelf -h /bin/ls | grep Type
  Type:                              EXEC (Executable file)

Every ELF file begins with a fixed-size header. In 64-bit ELF (Elf64_Ehdr) it is 64 bytes; in 32-bit (Elf32_Ehdr) it is 52 bytes. This header is the root of everything — it tells you what kind of file this is, what architecture it targets, and where to find the section-header table and program-header table.

Key fields:

The e_entry field is critical for the kernel: when execve() finishes mapping an ELF executable, it jumps to this address. For dynamically linked programs, this points to the dynamic linker (ld.so), not main(). For statically linked programs it points to the C runtime start (_start), which eventually calls main().

The e_type field of ET_DYN is used for both shared libraries and position-independent executables (PIE). This is why readelf -h /bin/ls on a modern distro shows DYN even though ls is an executable — PIE is the default for security reasons (ASLR).

#include <elf.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(void) {
    Elf64_Ehdr hdr;
    int fd = open("/bin/ls", O_RDONLY);
    read(fd, &hdr, sizeof(hdr));
    close(fd);

    printf("Magic: %02x %c%c%c\n",
           hdr.e_ident[0],
           hdr.e_ident[1], hdr.e_ident[2], hdr.e_ident[3]);
    printf("Class: %s\n", hdr.e_ident[EI_CLASS] == ELFCLASS64 ? "64-bit" : "32-bit");
    printf("Entry point: 0x%lx\n", hdr.e_entry);
    printf("Section headers: %d at offset 0x%lx\n", hdr.e_shnum, hdr.e_shoff);
    printf("Program headers: %d at offset 0x%lx\n", hdr.e_phnum, hdr.e_phoff);
    return 0;
}

Sections are the unit of organization that the compiler and linker care about. A section is a contiguous chunk of bytes with a name, a type, a set of flags, and an alignment requirement. The section-header table (SHT) is an array of Elf64_Shdr structs, each describing one section.

Key section types (sh_type):

• SHT_PROGBITS: arbitrary program data (code, data, debug info)
• SHT_SYMTAB: symbol table (one per file, all symbols)
• SHT_DYNSYM: dynamic symbol table (only the symbols needed at runtime)
• SHT_STRTAB: a null-terminated string table
• SHT_RELA / SHT_REL: relocation entries
• SHT_NOBITS: like PROGBITS but takes no file space (.bss)
• SHT_NOTE: vendor metadata, build IDs, ABI tags

Key section flags (sh_flags):

• SHF_ALLOC (A): must be in memory at runtime
• SHF_EXECINSTR (X): contains executable instructions
• SHF_WRITE (W): writable
• SHF_MERGE (M): entries can be merged (e.g., string literal deduplication)
• SHF_STRINGS (S): section contains null-terminated strings

The canonical sections every C program produces:

Sections can be split by the compiler for function-level GC: -ffunction-sections makes each function its own .text.<funcname> section, and the linker's --gc-sections then dead-strips unreferenced ones. The Linux kernel uses this aggressively.

# Compile a small file and inspect its sections
$ cat hello.c
#include <stdio.h>
const char msg[] = "hello";
int counter = 0;
int main(void) { puts(msg); return counter; }

$ gcc -c -O1 hello.c -o hello.o
$ readelf -S hello.o
# (abbreviated)
  [Nr] Name       Type     Flags  Size
  [ 1] .text      PROGBITS AX     0x001a
  [ 2] .rodata    PROGBITS A      0x0006   # "hello\0"
  [ 3] .data      PROGBITS AW     0x0000   # counter is zero-init -> .bss
  [ 4] .bss       NOBITS   AW     0x0004   # counter: 4 bytes, no file space
  [ 5] .comment   PROGBITS          ...
  [ 6] .symtab    SYMTAB            ...
  [ 7] .strtab    STRTAB            ...
  [ 8] .shstrtab  STRTAB            ...

While sections tell the linker how to lay things out, segments (described by program headers) tell the OS loader how to map the file into virtual memory. This is the view the kernel's execve() implementation reads — it ignores section headers entirely.

A program header (Elf64_Phdr) describes one segment:

Critical insight: p_memsz > p_filesz. The gap is zero-filled by the kernel (or dynamic linker). This is exactly what .bss needs — zero-initialized data takes no file space but needs real virtual pages.

Typical PT_LOAD segments for a simple binary:

1. RX segment (read+execute): contains .text, .rodata. Mapped as read-only executable pages.
2. RW segment (read+write): contains .data, .bss. Mapped as read-write non-executable pages.

Key other segment types:

• PT_INTERP: path to the dynamic linker (e.g., /lib64/ld-linux-x86-64.so.2). The kernel reads this and runs the interpreter instead of jumping to e_entry directly.
• PT_DYNAMIC: points to the .dynamic section which the dynamic linker uses to find needed libraries.
• PT_GNU_STACK: its p_flags field tells the kernel whether the stack should be executable. If absent or marked PF_X, the stack is executable — a security hazard. Modern toolchains set PF_R|PF_W only.
• PT_GNU_RELRO: tells the dynamic linker which region to mprotect(PROT_READ) after relocation is complete (the RELRO hardening technique).

The section-to-segment relationship: Many sections are packed into few segments. The linker decides which sections go into which segment based on compatibility (flags, alignment). readelf -l shows this mapping.

$ gcc -O1 hello.c -o hello
$ readelf -l hello
Elf file type is DYN (Position-Independent Executable file)
Entry point 0x1060
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0002d8 0x0002d8 R   0x8
  INTERP         0x000318 0x0000000000000318 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x000628 0x000628 R   0x1000
  LOAD           0x001000 0x0000000000001000 0x000195 0x000195 R E 0x1000
  LOAD           0x002000 0x0000000000002000 0x000114 0x000114 R   0x1000
  LOAD           0x002df0 0x0000000000003df0 0x000228 0x000230 RW  0x1000
  DYNAMIC        0x002e00 0x0000000000003e00 0x0001c0 0x0001c0 RW  0x8
  GNU_STACK      0x000000 0x0000000000000000 0x000000 0x000000 RW  0x10
# Note: GNU_STACK has RW flags (no X) -- stack is NOT executable. Good.

 Section to Segment mapping:
  Segment Sections...
   02     .interp
   03     .interp .dynsym .dynstr ... (first LOAD: read-only metadata)
   04     .text ...                   (second LOAD: code, R+X)
   07     .data .bss ...              (fourth LOAD: RW, memsz > filesz for .bss)

A symbol is a named entity — a function, a variable, or a label — with an address (or an offset within a section), a size, a type, and crucially, a binding and visibility.

Symbol binding (STB_*):

• STB_LOCAL: visible only within the translation unit. C static functions and variables. Not exported.
• STB_GLOBAL: visible to the entire link. Standard C functions and globals.
• STB_WEAK: like global but can be overridden. Used for default implementations that libraries can replace (e.g., __attribute__((weak))).

Symbol type (STT_*):

• STT_FUNC: a function
• STT_OBJECT: a data object (variable, array)
• STT_SECTION: refers to a section itself
• STT_FILE: source filename
• STT_NOTYPE: unknown type (often assembly labels)
• STT_TLS: thread-local storage

Symbol visibility (STV_*):

• STV_DEFAULT: default visibility; global/weak symbols are exported.
• STV_HIDDEN: not visible outside the shared object even if global. Set by __attribute__((visibility("hidden"))) or -fvisibility=hidden. Critical for shared library ABIs.
• STV_PROTECTED: exported but cannot be overridden by a preloaded .so.

Two symbol tables in one file:

1. .symtab: the full symbol table. Contains every symbol the compiler generated, including locals. Used by debuggers and the linker. Often stripped from production binaries with strip.
2. .dynsym: the minimal dynamic symbol table. Only the symbols that the dynamic linker needs to resolve at runtime. Cannot be stripped — the dynamic linker reads it.

The nm tool is the fastest way to inspect symbols. Its one-letter codes (lowercase = local, uppercase = global) are a shorthand for the above: T/t = text (function), D/d = data, B/b = BSS, U = undefined (to be resolved from another object), W/w = weak.

$ cat symbols.c
#include <stdio.h>
static int hidden_counter = 0;   // STB_LOCAL
int global_counter = 0;          // STB_GLOBAL, STT_OBJECT, .bss
extern void other_func(void);    // STB_GLOBAL, undefined

void my_func(void) {             // STB_GLOBAL, STT_FUNC
    hidden_counter++;
    global_counter++;
    other_func();
}

$ gcc -c symbols.c -o symbols.o
$ nm symbols.o
0000000000000000 b hidden_counter   # lowercase b = local BSS
0000000000000004 B global_counter   # uppercase B = global BSS
                 U other_func       # U = undefined (external reference)
0000000000000000 T my_func          # T = global function in .text

$ readelf -s symbols.o | grep -v 'FILE\|SECTION'
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     7: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    4 hidden_counter
     8: 0000000000000000    22 FUNC    GLOBAL DEFAULT    1 my_func
     9: 0000000000000004     4 OBJECT  GLOBAL DEFAULT    4 global_counter
    10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND other_func

When the compiler generates a .o file, it does not know the final address of symbols defined in other files. It emits a placeholder and records a relocation entry saying "fix this up when you know the real address."

A relocation entry (Elf64_Rela) has three key fields:

• r_offset: where in the section to apply the fix (byte offset, or a virtual address)
• r_info: encodes the symbol index (what symbol) and the relocation type (how to compute the fix)
• r_addend: a constant to add to the computed value (for RELA-style relocations)

Relocation types are architecture-specific. Common x86-64 types:

• R_X86_64_64: absolute 64-bit address. Used for data references.
• R_X86_64_PC32: PC-relative 32-bit. Used for call and jmp within 2 GB.
• R_X86_64_PLT32: PC-relative call through the Procedure Linkage Table (for dynamic linking).
• R_X86_64_GOTPCRELX: access the Global Offset Table. Used for PIC data references.

The formula (simplified): *(location) = symbol_address + addend - location_address

This is the linker's core job: walk every relocation entry, look up the symbol in the symbol table, compute the formula, and patch the bytes.

Static vs dynamic relocations:

• Static relocations (SHT_RELA in .o files) are resolved at link time by ld.
• Dynamic relocations (SHT_RELA in .so/PIE) are left in the final binary and resolved at load time by ld.so.

The PLT and GOT (for dynamic linking): instead of patching every call site at load time, the linker routes external function calls through the Procedure Linkage Table (PLT) and data accesses through the Global Offset Table (GOT). The GOT holds absolute addresses filled by the dynamic linker; PLT stubs jump through GOT entries. This indirection is what makes shared libraries work without modifying the .text segment.

# See relocations in a .o file
$ gcc -c -O1 symbols.c -o symbols.o
$ readelf -r symbols.o

Relocation section '.rela.text' at offset 0x... contains 2 entries:
  Offset          Info           Type            Sym. Value  Sym. Name + Addend
000000000000000b  000a00000004 R_X86_64_PLT32    0000000000000000 other_func - 4
# ^^^^ at byte 0x0b in .text, patch a PLT-relative 32-bit offset to other_func

# After linking, check the PLT stubs
$ gcc symbols.c other.c -o prog
$ objdump -d -j .plt prog | head -20
Disassembly of section .plt:
0000000000001020 <other_func@plt>:
    1020:  ff 25 e2 2f 00 00    jmpq *0x2fe2(%rip)   # GOT entry
    1026:  68 00 00 00 00       push $0x0
    102b:  e9 e0 ff ff ff       jmp  1010 <_init+0x10>  # resolver

objdump is the Swiss Army knife of binary inspection. It can disassemble code, dump raw section contents, show relocation entries, and print dynamic linking information.

Essential flags:

Reading the disassembly output — each line has:

1. Virtual address
2. Raw hex bytes (the machine code)
3. Mnemonic and operands

Arrows in AT&T syntax point from source to destination, which is the opposite of Intel syntax. The suffixes b/w/l/q mean byte/word/long(32-bit)/quad(64-bit). You will read a lot of disassembly while debugging kernel code, so training your eye now on toy examples pays off enormously.

Combining -S with DWARF: When code is compiled with -g, objdump -S inserts the C source lines above each block of generated instructions. This is one of the most educational ways to understand what the compiler does to your code.

-j .rodata is useful for finding string literals embedded in a binary — sometimes you can identify what a stripped binary does just from its strings.

$ cat add.c
int add(int a, int b) { return a + b; }
int main(void) { return add(2, 3); }

$ gcc -O0 -g add.c -o add
$ objdump -d -M intel -j .text --no-show-raw-insn add

Disassembly of section .text:

0000000000001129 <add>:
    1129:  push   rbp
    112a:  mov    rbp,rsp
    112d:  mov    DWORD PTR [rbp-0x4],edi   ; a
    1130:  mov    DWORD PTR [rbp-0x8],esi   ; b
    1133:  mov    edx,DWORD PTR [rbp-0x4]
    1136:  mov    eax,DWORD PTR [rbp-0x8]
    1139:  add    eax,edx
    113b:  pop    rbp
    113c:  ret

0000000000001140 <main>:
    1140:  push   rbp
    1141:  mov    rbp,rsp
    1144:  mov    esi,0x3                   ; b=3
    1149:  mov    edi,0x2                   ; a=2
    114e:  call   1129 <add>
    1153:  pop    rbp
    1154:  ret

Beyond readelf and objdump, a few focused tools are indispensable:

nm — symbol lister Shows the symbol table in a compact format. Key use: quickly see what a .o or library exports, find undefined references, or check that an optimization (like dead-code stripping) actually removed a symbol. nm -u shows only undefined symbols; nm -D shows only dynamic symbols (from .dynsym); nm -S shows size next to each symbol.

size — section size summary Prints the size of .text, .data, and .bss (and total) for each object or binary. The output is deceptively simple but immediately useful: you can see how much your binary will consume in memory, whether your changes grew the code, and whether constants are going where you expect. The Berkeley format (size --format=Berkeley) is the default; SysV format (size --format=SysV) shows every section individually.

strip — symbol removal Production and embedded binaries are stripped to save space and reduce information leakage. strip by default removes .symtab and .strtab but preserves .dynsym (which cannot be stripped without breaking dynamic linking). Options:

• strip --strip-debug: remove only debug sections (.debug_*, .symtab), keep .dynsym
• strip --strip-unneeded: remove everything not needed at runtime (same as above, usually)
• strip -s: the most aggressive; removes everything removable

The Linux kernel itself ships vmlinux with full symbols (for perf, crash, kgdb), but the compressed vmlinuz that goes to the bootloader is stripped.

objcopy — binary manipulation The most powerful of the bunch. It can:

• Convert ELF to raw binary: objcopy -O binary vmlinux vmlinux.bin (used in kernel build for some architectures)
• Remove or rename sections: objcopy --remove-section .comment
• Add a section from a file: objcopy --add-section .firmware=fw.bin
• Change section flags
• Extract DWARF separately: objcopy --only-keep-debug vmlinux vmlinux.debug && strip --strip-debug vmlinux

This debug-split workflow (keep debug in a .debug file, strip the binary, link them via .gnu_debuglink) is exactly how distribution packages like linux-image-dbg work.

# nm examples
$ nm -S --size-sort /bin/ls | tail -5   # 5 largest symbols by size

# size examples
$ size add.o add
   text    data     bss     dec     hex filename
     22       0       0      22      16 add.o
   4208     600      16    4824    12d8 add

# strip workflow: keep debug, strip binary, link them
$ gcc -g -O1 add.c -o add
$ objcopy --only-keep-debug add add.debug
$ strip --strip-debug add
$ objcopy --add-gnu-debuglink=add.debug add
$ ls -lh add add.debug
-rwxr-xr-x add       (small, no debug)
-rwxr-xr-x add.debug (just debug info)
# gdb will automatically find add.debug via the .gnu_debuglink note

# objcopy: raw binary extraction (used in kernel Makefile for ARM/RISC-V)
$ objcopy -O binary -j .text add text.bin
$ xxd text.bin | head -3

This is the single most commonly confused concept in ELF, so let us be very precise.

Sections exist for the linker and debugger. They are the unit of layout control in linker scripts, the unit of relocation (.rela.text), and the thing tools like gdb and perf use to find code and data. An ELF .o file only has sections — no segments. The section-header table is optional in the final binary (the kernel ignores it during execve()), but present for tooling.

Segments (program headers) exist for the OS loader. The kernel's load_elf_binary() in fs/binfmt_elf.c loops over PT_LOAD program headers, calls elf_map() (ultimately mmap()), and builds the process's virtual address space. It never looks at section headers.

Analogy: Think of a warehouse. Sections are the labeled bins ("power tools", "hand tools", "hardware") — useful for finding things. Segments are the fire compartments — what matters for safety (execution protection). Many bins may live in one compartment; a compartment's properties (fire resistance = W/X flags) apply to everything inside it.

The mapping is many-to-one: A PT_LOAD segment typically contains multiple sections. The linker packs compatible sections together:

• Sections with SHF_ALLOC | SHF_EXECINSTR → R+X PT_LOAD segment
• Sections with SHF_ALLOC | SHF_WRITE → R+W PT_LOAD segment
• Sections with SHF_ALLOC only (no write, no exec) → R-only PT_LOAD segment

Why does this matter? When you write a kernel linker script, you are explicitly choosing which sections go into which output section and what address they land at. The script also controls how sections become segments. Understanding this mapping is what separates someone who can read a linker script from someone who can write one.

# Visualize the section-to-segment mapping
$ readelf -l /bin/ls

# At the bottom:
 Section to Segment mapping:
  Segment Sections...
   00      (PHDR)
   01      .interp
   02      .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag
           .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r
           .rela.dyn .rela.plt
   03      .init .plt .plt.got .plt.sec .text .fini     # R+X segment
   04      .rodata .eh_frame_hdr .eh_frame              # R-only segment
   05      .init_array .fini_array .dynamic .got .data .bss  # R+W segment

# .text and .rodata are in DIFFERENT segments!
# .text is R+X, .rodata is R-only. The linker keeps them separate
# so .rodata pages are not accidentally made executable.

vmlinux is the fully-linked, uncompressed ELF image of the Linux kernel. It is the direct output of ld invoked by the kernel's top-level Makefile, linked according to arch/<arch>/kernel/vmlinux.lds (a kernel linker script).

Why is it huge? vmlinux for a typical x86_64 defconfig build is around 30–60 MB. It contains:

• All compiled kernel code (.text)
• All kernel data (.data, .bss, .rodata)
• Extensive DWARF debug information (.debug_*) if compiled with CONFIG_DEBUG_INFO=y
• The symbol table (.symtab), which is used by /proc/kallsyms, perf, crash, and kgdb

What the kernel does with its own ELF: The compressed vmlinuz or bzImage that actually boots is not ELF — it is a self-decompressing executable with the compressed vmlinux payload inside. The decompressor unpacks vmlinux into memory at the address the linker script specified, then jumps to the kernel entry point. This address is encoded in e_entry.

Special kernel sections you will encounter in kernel development:

• .init.text, .init.data: code and data only needed during boot. Freed after do_initcalls() completes — you have probably seen the message "Freeing unused kernel memory: XXXX K".
• __ksymtab, __ksymtab_strings, __kcrctab: the kernel's exported symbol table (EXPORT_SYMBOL). Kernel modules are linked against this, not .symtab.
• .altinstructions, .altinstr_replacement: alternative instructions patched at boot (e.g., for SMP vs UP, or for CPU feature detection like Spectre mitigations).
• __param: module parameter descriptors (also used for CONFIG_ boot parameters).
• .fixup, __ex_table: the exception table — maps addresses in kernel code to fixup handlers for when user-space pointer accesses fault.

/proc/kallsyms is generated from vmlinux's symbol table by the build system (specifically, scripts/kallsyms.c). It is embedded into the kernel image itself so tools can do symbolic stack traces without needing the vmlinux file at runtime.

# If you have a kernel build tree:
$ ls -lh vmlinux
-rwxr-xr-x 1 user user 54M vmlinux

$ readelf -h vmlinux | head -20
  Type:   EXEC (Executable file)   # or ET_DYN on some arm64 configs
  Machine: Advanced Micro Devices X86-64
  Entry point address: 0xffffffff81000000   # kernel virtual address!

# List kernel sections and sizes
$ size --format=SysV vmlinux | grep -E 'text|data|bss|init'
.text        : 14524416
.rodata      :  5423104
.data        :  2097152
.bss         :  3145728
.init.text   :   786432    # freed after boot!
.init.data   :   524288    # freed after boot!

# The exported symbol table (what modules link against)
$ readelf -S vmlinux | grep ksymtab
  [ ] __ksymtab          PROGBITS  ...
  [ ] __ksymtab_gpl      PROGBITS  ...

# Cross-check with /proc/kallsyms at runtime
$ sudo grep ' T do_sys_open' /proc/kallsyms
ffffffff811b6e10 T do_sys_open

A Build ID is a 160-bit SHA1 hash (or 128-bit MD5, or a random UUID) computed over the binary's code and data sections and embedded as an ELF note in .note.gnu.build-id. It is added by the linker with --build-id (GCC/clang enable this by default on most distributions).

Build IDs solve a critical problem: how do you match a stripped binary running in production with the correct .debug file? The answer: compare build IDs. Tools like gdb, crash, and eu-unstrip all use build IDs to automatically locate debug files under /usr/lib/debug/.build-id/<xx>/<rest>.debug.

In the kernel world, the build ID is used by perf to identify which vmlinux corresponds to a recorded profile. If you upgrade your kernel and try to analyze an old perf.data, perf checks the build ID embedded in the data file against vmlinux and warns you if they do not match.

Reading a build ID:

$ readelf -n /bin/ls | grep -A4 'GNU'
Displaying notes found in: .note.gnu.build-id
  Owner        Data size  Description
  GNU          0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: a8d2b4c1f3...<40 hex chars>

Other .note sections:

• .note.ABI-tag: minimum Linux kernel version required to run the binary.
• .note.gnu.property: encodes CPU feature requirements and security properties (e.g., IBT for Intel's Indirect Branch Tracking, SHSTK for Shadow Stack — both are CET hardening features). The kernel checks these at execve() to decide whether to enable CET for the process.

Notes are a general-purpose metadata mechanism: SHT_NOTE sections hold a vendor name, a type, and arbitrary data. They are small, ignored by the loader, but invaluable for tooling.

# Check build ID
$ readelf -n /bin/ls | grep 'Build ID'
    Build ID: e8e46bdc2e06f4b42cba0e3c7a3ab1d30bfbef81

# Find the corresponding debug file on a Debian/Ubuntu system
$ B=$(readelf -n /bin/ls | awk '/Build ID/{print $NF}')
$ ls /usr/lib/debug/.build-id/${B:0:2}/${B:2}.debug 2>/dev/null
/usr/lib/debug/.build-id/e8/e46bdc2e06f4b42cba0e3c7a3ab1d30bfbef81.debug

# Check GNU property notes (security features)
$ readelf -n /bin/ls | grep -A2 'GNU_PROPERTY'
  Displaying notes found in: .note.gnu.property
  Owner    Data size    Description
  GNU      0x00000020   NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature used: x86, x87, MMX, XMM, YMM
                  x86 ISA needed: x86-64-baseline
                  x86 feature needed: IBT, SHSTK