OBJDUMP(1)

πŸ’– NAME πŸ’–

objdump β€” the way that you peek inside object files and get ALL the tea β˜•βœ¨

This is the manual for objdump from the GNU Development Tools, bestie. Let's get into it 🫢


🌸 SYNOPSIS 🌸

objdump [-a|--archive-headers]
        [-b bfdname|--target=bfdname]
        [-C|--demangle[=style] ]
        [-d|--disassemble[=symbol]]
        [-D|--disassemble-all]
        [-z|--disassemble-zeroes]
        [-EB|-EL|--endian={big | little }]
        [-f|--file-headers]
        [-F|--file-offsets]
        [--file-start-context]
        [-g|--debugging]
        [-e|--debugging-tags]
        [-h|--section-headers|--headers]
        [-i|--info]
        [-j section|--section=section]
        [-l|--line-numbers]
        [-S|--source]
        [--source-comment[=text]]
        [-m machine|--architecture=machine]
        [-M options|--disassembler-options=options]
        [-p|--private-headers]
        [-P options|--private=options]
        [-r|--reloc]
        [-R|--dynamic-reloc]
        [-s|--full-contents]
        [-Z|--decompress]
        [-W|--dwarf]
        [-Wa|--dwarf=abbrev]
        [-WA|--dwarf=addr]
        [-Wr|--dwarf=aranges]
        [-Wc|--dwarf=cu_index]
        [-WL|--dwarf=decodedline]
        [-Wf|--dwarf=frames]
        [-WF|--dwarf=frames-interp]
        [-Wg|--dwarf=gdb_index]
        [-Wi|--dwarf=info]
        [-Wk|--dwarf=links]
        [-Wo|--dwarf=loc]
        [-Wm|--dwarf=macro]
        [-Wp|--dwarf=pubnames]
        [-Wt|--dwarf=pubtypes]
        [-WR|--dwarf=Ranges]
        [-Wl|--dwarf=rawline]
        [-Ws|--dwarf=str]
        [-WO|--dwarf=str-offsets]
        [-Wu|--dwarf=trace_abbrev]
        [-WT|--dwarf=trace_aranges]
        [-WU|--dwarf=trace_info]
        [-WK|--dwarf=follow-links]
        [-WN|--dwarf=no-follow-links]
        [-WD|--dwarf=use-debuginfod]
        [-WE|--dwarf=do-not-use-debuginfod]
        [--debug-dir=dir]
        [--map-global-vars]
        [-L|--process-links]
        [--ctf=section]
        [--sframe=section]
        [-G|--stabs]
        [-t|--syms]
        [-T|--dynamic-syms]
        [-x|--all-headers]
        [-w|--wide]
        [--start-address=address]
        [--stop-address=address]
        [--no-addresses]
        [--prefix-addresses]
        [--[no-]show-raw-insn]
        [--adjust-vma=offset]
        [--show-all-symbols]
        [--dwarf-depth=n]
        [--dwarf-start=n]
        [--ctf-parent=section]
        [--no-recurse-limit|--recurse-limit]
        [--special-syms]
        [--prefix=prefix]
        [--prefix-strip=level]
        [--insn-width=width]
        [--visualize-jumps[=color|=extended-color|=off]
        [--disassembler-color=[off|terminal|on|extended]
        [-U method] [--unicode=method]
        [-V|--version]
        [-H|--help]
        objfile...

✨ DESCRIPTION ✨

Okay so objdump shows you info about one or more object files β€” like, it dumps the *obj*ects, the name is doing exactly what it says on the tin πŸ’… The options are what control which particular info you get to see. This stuff is mostly for the girlies working on compilation tools themselves, not so much for programmers who just want their program to compile and work. Different audience, different vibe, no shade 🌈

objfile... are the object files you wanna examine. And when you specify archives? objdump shows you information on each of the member object files. Every single one. It's thorough like that 😌


πŸ‘‘ OPTIONS πŸ‘‘

The long and short forms of options, shown here as alternatives, are equivalent β€” same energy, different spelling, periodt ✨

⚠️ Heads up bestie: at least one option from the list -a,-d,-D,-e,-f,-g,-G,-h,-H,-p,-P,-r,-R,-s,-S,-t,-T,-V,-x must be given. You cannot just run it bare and expect the tea. Pick something πŸ’€
  • -a, --archive-header β€” If any of the objfile files are archives, display the archive header information (in a format similar to ls -l). Besides the info you could already list with ar tv, objdump -a also shows you the object file format of each archive member. Extra credit info, we love to see it πŸŽ€
  • --adjust-vma=offset β€” When dumping info, first add offset to all the section addresses. This is useful if the section addresses don't correspond to the symbol table β€” which can happen when you're putting sections at particular addresses using a format that can't represent section addresses, like a.out. So basically it's the little fixer-upper for when your addresses are giving mismatched πŸ’…
  • -b bfdname, --target=bfdname β€” Specify that the object-code format for the object files is bfdname. Ngl this option may not even be necessary, because objdump can automatically recognize many formats on its own. She's smart like that 😌

For example:

objdump -b oasys -m vax -h fu.o

This displays summary information from the section headers (-h) of fu.o, which is explicitly identified (-m) as a VAX object file in the format produced by Oasys compilers. And if you wanna know what formats are even available? List them with the -i option, bestie πŸ¦‹

  • -C, --demangle[=style] β€” Decode (demangle) low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes C++ function names readable. Different compilers have different mangling styles, which is messy of them fr fr. The optional demangling style argument can be used to choose an appropriate demangling style for your compiler ✨
  • --recurse-limit, --no-recurse-limit, --recursion-limit, --no-recursion-limit β€” Enables or disables a limit on the amount of recursion performed whilst demangling strings. Here's the thing: since the name mangling formats allow for an infinite level of recursion, it is possible to create strings whose decoding will exhaust the amount of stack space available on the host machine, triggering a memory fault 😭 The limit tries to prevent this from happening by restricting recursion to 2048 levels of nesting.

The default is for this limit to be enabled, but disabling it may be necessary in order to demangle truly complicated names. But note: if the recursion limit is disabled then stack exhaustion is possible and any bug reports about such an event will be rejected. So like… you were warned, bestie πŸ’€

  • -g, --debugging β€” Display debugging information. This attempts to parse STABS debugging format information stored in the file and print it out using a C like syntax. If no STABS debugging was found, this option falls back on the -W option to print any DWARF information in the file. She's got a backup plan, main character energy πŸ‘‘
  • -e, --debugging-tags β€” Like -g, but the information is generated in a format compatible with the ctags tool. Same tea, different cup πŸ“
  • -d, --disassemble, --disassemble=symbol β€” Display the assembler mnemonics for the machine instructions from the input file. This option only disassembles those sections which are expected to contain instructions. If the optional symbol argument is given (perhaps multiple times), then display the assembler mnemonics starting at (all the) symbol. If symbol is a function name then disassembly will stop at the end of the function, otherwise it will stop when the next symbol is encountered. And if there are no matches for any symbol? Nothing will be displayed. Nothing. Silence. πŸ’€

Note: if the --dwarf=follow-links option is enabled then any symbol tables in linked debug info files will be read in and used when disassembling. iykyk πŸ”₯

  • -D, --disassemble-all β€” Like -d, but disassemble the contents of all non-empty non-bss sections, not just those expected to contain instructions. -j may be used to select specific sections. She's an overachiever, we respect it 😌

This option also has a subtle effect on the disassembly of instructions in code sections. When option -d is in effect, objdump will assume that any symbols present in a code section occur on the boundary between instructions and it will refuse to disassemble across such a boundary. When option -D is in effect, however, this assumption is supressed. This means that it is possible for the output of -d and -D to differ if, for example, data is stored in code sections. So yeah, they can genuinely disagree, that's not a bug bestie that's the whole point ✨

If the target is an ARM architecture this switch also has the effect of forcing the disassembler to decode pieces of data found in code sections as if they were instructions πŸ‘€

Note: if the --dwarf=follow-links option is enabled then any symbol tables in linked debug info files will be read in and used when disassembling.

  • --no-addresses β€” When disassembling, don't print addresses on each line or for symbols and relocation offsets. In combination with --no-show-raw-insn this may be useful for comparing compiler output. Clean, minimal, no clutter πŸŽ€
  • --prefix-addresses β€” When disassembling, print the complete address on each line. This is the older disassembly format. Vintage, if you will πŸ¦‹
  • -EB, -EL, --endian={big|little} β€” Specify the endianness of the object files. This only affects disassembly. This can be useful when disassembling a file format which does not describe endianness information, such as S-records. Pick a lane, big or little πŸ’…
  • -f, --file-headers β€” Display summary information from the overall header of each of the objfile files. The big picture, the bird's eye view 🌈
  • -F, --file-offsets β€” When disassembling sections, whenever a symbol is displayed, also display the file offset of the region of data that is about to be dumped. If zeroes are being skipped, then when disassembly resumes, tell the user how many zeroes were skipped and the file offset of the location from where the disassembly resumes. And when dumping sections, display the file offset of the location from where the dump starts. Receipts for everything, love that for us 🧾✨
  • --file-start-context β€” Specify that when displaying interlisted source code/disassembly (assumes -S) from a file that has not yet been displayed, extend the context to the start of the file. More context is always the move, ngl 🫢
  • -h, --section-headers, --headers β€” Display summary information from the section headers of the object file.

File segments may be relocated to nonstandard addresses, for example by using the -Ttext, -Tdata, or -Tbss options to ld. However, some object file formats, such as a.out, do not store the starting address of the file segments. In those situations, although ld relocates the sections correctly, using objdump -h to list the file section headers cannot show the correct addresses. Instead, it shows the usual addresses, which are implicit for the target. So it's not lying, it's just working with what it's got 😭

Note: in some cases it is possible for a section to have both the READONLY and the NOREAD attributes set. In such cases the NOREAD attribute takes precedence, but objdump will report both since the exact setting of the flag bits might be important. Both, always both, precision is the vibe πŸ’…

  • -H, --help β€” Print a summary of the options to objdump and exit. Your little cheat sheet, bestie 🌸
  • -i, --info β€” Display a list showing all architectures and object formats available for specification with -b or -m. The menu of options, so to speak πŸ‘‘

more coming, don't go anywhere πŸ’œ

  • -j name, --section=name β€” ok so this one is literally "show me just the section called name, bestie" πŸ’… and you can drop it as many times as you want, once for each section, and it'll stack them all up for you. Repeat it, no cap.
  • --map-global-vars β€” this slays for global variable info 🫢 and it only works when the object file was compiled with the debug option, periodt. More precisely β€” and yes I'm being precise β€” it relies on DWARF2 debug information entries. It's giving "track the location and type of every single global variable in this object file," iconic for debugging fr fr.
  • -L, --process-links β€” shows you the contents of the non-debug sections that live in separate debuginfo files linked to the main file 🌸. Heads up: this automatically implies the -WK option (yes, sneakily), and only the sections you actually asked for with other command line options will show up. So you don't get everything, you get what you requested. Vibe check passed.
  • -l, --line-numbers β€” labels the display using debugging information, so you get the filename and source line numbers that match the object code or relocs being shown ✨. Only useful with -d, -D, or -r though, so don't come at it alone, it needs a friend.
  • -m machine, --architecture=machine β€” tells objdump which architecture to use when disassembling 🧚. Super handy when you're disassembling object files that don't describe their architecture info at all, like S-records. You can list all the available architectures with the -i option. Go look, it's free.

For most architectures you can hand over an architecture name and a machine name, separated by a colon β€” so like foo:bar would point at the bar machine type inside the foo architecture πŸ‘‘. Genuinely helpful when objdump has been configured to support multiple architectures at once.

If the target is an ARM architecture then this switch has a lil extra effect: it restricts the disassembly to only those instructions that the architecture specified by machine actually supports πŸ”₯. And if you're forced to use this switch because your input file has zero architecture info, but you also want to disassemble all the instructions β€” use -marm. Got it? -marm. Write it down.

  • -M options, --disassembler-options=options β€” passes target-specific info through to the disassembler πŸ’œ. Only supported on some targets, so don't be shocked if your target just ignores you. If you need more than one disassembler option, you can either use multiple -M options, or stack them all together into one comma separated list. Either way, slay.

Ok now the big one, buckle up bestie, this is the choose-your-own-adventure part 🌈.

For ARC: dsp controls the printing of DSP instructions, spfp selects the printing of FPX single precision FP instructions, dpfp selects the printing of FPX double precision FP instructions, quarkse_em selects the printing of special QuarkSE-EM instructions, fpuda selects the printing of double precision assist instructions, fpus selects the printing of FPU single precision FP instructions, while fpud selects the printing of FPU double precision FP instructions πŸŽ€. On top of all that, you can choose to have all the immediates printed in hexadecimal using hex. By default, the short immediates get printed using the decimal representation, while the long immediate values get printed as hexadecimal. Cute, right?

cpu=... lets you enforce a particular ISA when disassembling instructions, overriding the -m value or whatever's sitting in the ELF file πŸ’…. This might be useful to select ARC EM or HS ISA, because the architecture is the same for those and the disassembler relies on private ELF header data to decide if the code is for EM or HS. You can specify this option multiple times β€” only the latest value will be used, no cap. Valid values are the same as for the assembler's -mcpu=... option.

If the target is an ARM architecture then this switch can be used to select which register name set gets used during disassembly ✨. Specifying -M reg-names-std (the default) selects the register names as used in ARM's instruction set documentation, but with register 13 called sp, register 14 called lr and register 15 called pc. Specifying -M reg-names-apcs selects the name set used by the ARM Procedure Call Standard, whilst specifying -M reg-names-raw just uses r followed by the register number. Simple. Clean. Iconic.

There are also two variants on the APCS register naming scheme, enabled by -M reg-names-atpcs and -M reg-names-special-atpcs, which use the ARM/Thumb Procedure Call Standard naming conventions πŸ¦‹ (either with the normal register names or the special register names β€” your call, main character).

This option can also be used for ARM architectures to force the disassembler to interpret all instructions as Thumb instructions, using the switch --disassembler-options=force-thumb πŸ”₯. This can be useful when you're attempting to disassemble thumb code produced by other compilers. Other compilers stay doing their own thing, so yeah.

For AArch64 targets this switch can be used to set whether instructions are disassembled as the most general instruction using the -M no-aliases option, or whether instruction notes should be generated as comments in the disassembly using -M notes ⭐. In addition, the -M annotate option can be used to customise the handling of undefined instructions when disassembling executables and shared libraries. Normally the disassembler will just show the hexadecimal value of the undefined instruction, but if annotation is enabled it will first try to find a symbol whose value matches the instruction's encoding. If there's a match, then the symbol name gets displayed instead πŸ‘‘. This can be useful when disassembling non-code sections which may contain function and data addresses. Big brain energy.

For the x86, some of the options duplicate functions of the -m switch, but allow finer grained control 😭:

  • "x86-64", "i386", "i8086" β€” select disassembly for the given architecture.
  • "intel", "att" β€” select between intel syntax mode and AT&T syntax mode πŸ’….
  • "amd64", "intel64" β€” select between AMD64 ISA and Intel64 ISA.
  • "intel-mnemonic", "att-mnemonic" β€” select between intel mnemonic mode and AT&T mnemonic mode. Note: "intel-mnemonic" implies "intel" and "att-mnemonic" implies "att". The implications are implicating, bestie.
  • "addr64", "addr32", "addr16", "data32", "data16" β€” specify the default address size and operand size. These five options will be overridden if "x86-64", "i386" or "i8086" appear later in the option string. Order matters, so watch it 🫢.
  • "suffix" β€” when in AT&T mode, and also for a limited set of instructions when in Intel mode, this instructs the disassembler to print a mnemonic suffix even when the suffix could be inferred by the operands or, for certain instructions, the execution mode's defaults.
  • "annotate-immediates" β€” display the symbol associated with immediate values, should there be one 🌸. Only works on executable binaries and shared libraries, not static object files. Sorry to the object file girlies.

For PowerPC, the -M argument raw selects disassembly of hardware insns rather than aliases πŸ”₯. For example, you'll see "rlwinm" rather than "clrlwi", and "addi" rather than "li". All of the -m arguments for gas that select a CPU are supported. These are: 403, 405, 440, 464, 476, 601, 603, 604, 620, 7400, 7410, 7450, 7455, 750cl, 821, 850, 860, a2, booke, booke32, cell, com, e200z2, e200z4, e300, e500, e500mc, e500mc64, e500x2, e5500, e6500, efs, power4, power5, power6, power7, power8, power9, power10, power11, ppc, ppc32, ppc64, ppc64bridge, ppcps, pwr, pwr2, pwr4, pwr5, pwr5x, pwr6, pwr7, pwr8, pwr9, pwr10, pwr11, pwrx, titan, vle, and future πŸ‘‘. Then 32 and 64 modify the default or a prior CPU selection, disabling and enabling 64-bit insns respectively. In addition, altivec, any, lsp, htm, vsx, spe and spe2 add capabilities to a previous or later CPU selection. Careful with any though β€” it will disassemble any opcode known to binutils, but in cases where an opcode has two different meanings or different arguments, you may not see the disassembly you expect πŸ’€. And if you disassemble without giving a CPU selection, a default will be chosen from information gleaned by BFD from the object file's headers, but the result again may not be as you expect. Rude but true.

For RISC-V, the following options are supported πŸŽ€:

  • "max" β€” disassemble without checking the architecture string. This is a best effort mode, so for overlapping ISA extensions the first match (possibly incorrect in a given context) will be used to decode the instruction. It's useful if the ELF file doesn't expose an ISA string, preventing automatic ISA subset deduction, and the default fallback ISA string ("rv64gc") doesn't cover all instructions in the binary.
  • "numeric" β€” print numeric register names, rather than ABI names (e.g., print "x2" instead of "sp"). Numbers over names, we respect it.
  • "no-aliases" β€” disassemble only into canonical instructions. For example, compressed instructions will be represented as such ("addi sp,sp,-128" will be "c.addi16sp sp,-128") ✨.
  • "priv-spec=SPEC" β€” print the CSR according to the chosen privilege spec version (e.g., 1.10, 1.11, 1.12, 1.13).

For MIPS, this option controls the printing of instruction mnemonic names and register names in disassembled instructions πŸ¦‹. Multiple selections from the following may be specified as a comma separated string, and invalid options are ignored (so objdump is just gonna pretend you didn't say that πŸ™ˆ):

  • "no-aliases" β€” print the 'raw' instruction mnemonic instead of some pseudo instruction mnemonic. I.e., print 'daddu' or 'or' instead of 'move', 'sll' instead of 'nop', etc.
  • "msa" β€” disassemble MSA instructions πŸ’….
  • "virt" β€” disassemble the virtualization ASE instructions.
  • "xpa" β€” disassemble the eXtended Physical Address (XPA) ASE instructions.
  • "gpr-names=ABI" β€” print GPR (general-purpose register) names as appropriate for the specified ABI. By default, GPR names are selected according to the ABI of the binary being disassembled.
  • "fpr-names=ABI" β€” print FPR (floating-point register) names as appropriate for the specified ABI. By default, FPR numbers are printed rather than names.
  • "cp0-names=ARCH" β€” print CP0 (system control coprocessor; coprocessor 0) register names as appropriate for the CPU or architecture specified by ARCH. By default, CP0 register names are selected according to the architecture and CPU of the binary being disassembled.
  • hwr-names=ARCH β€” prints HWR (that's hardware register, the thing the rdhwr instruction is obsessed with) names that fit the CPU or architecture you name in ARCH. Don't pass anything and it'll just vibe-check the architecture + CPU of whatever binary you're disassembling and pick accordingly. ✨
    • reg-names=ABI β€” prints GPR and FPR names matching the ABI you picked. πŸ’…
    • reg-names=ARCH β€” prints CPU-specific register names (CP0 register and HWR names, bestie) that match the CPU or architecture you picked.

For every single one of the options above, ABI or ARCH can be a number instead of a name, and then you get numbers printed instead of names for whichever register types you asked for. Wanna see every available value of ABI and ARCH? --help. That's it, that's the list. 🫢

And for VAX specifically: you can hand over function entry addresses with -M entry:0xf00ba. Use it multiple times and you can properly disassemble VAX binary files that have no symbol tables (ROM dumps, looking at you πŸ‘€). Without it, that function entry mask gets decoded as VAX instructions, which would probably make the rest of the function get disassembled completely wrong. 😭 So like. Don't skip it.


  • -p, --private-headers β€” prints info that's specific to the object file format. What exactly shows up depends on the object file format, because of course it does. For some formats? Nothing extra gets printed. Sorry babe. πŸ’€
  • -P options, *--private=options* β€” also prints format-specific info, but this time options is a comma-separated list that depends on the format (and the lists of options get shown in the help, bless).

For XCOFF, the available options are:

  • header
  • aout
  • sections
  • syms
  • relocs
  • lineno,
  • loader
  • except
  • typchk
  • traceback
  • toc
  • ldinfo

For PE, the available options are:

  • header
  • sections

Not every object format supports this option, just so you know. In particular, the ELF format does not use it. πŸ™ˆ

  • -r, --reloc β€” prints the relocation entries of the file. Combine it with -d or -D and the relocations get printed interspersed with the disassembly, which is lowkey the best way to read them. πŸ”₯
  • -R, --dynamic-reloc β€” prints the dynamic relocation entries of the file. This is only meaningful for dynamic objects, like certain types of shared libraries. And same as -r: pair it with -d or -D and the relocations show up interspersed with the disassembly.
Note: objdump does not support displaying RELR type relocations. Those can be displayed by the readelf program. Not us. Go ask readelf. πŸ’…
  • -s, --full-contents β€” displays the full contents of sections, often used together with -j to request specific sections. By default all non-empty non-bss sections are displayed. By default any compressed section will be displayed in its compressed form. Wanna see it decompressed? Add the -Z option to the command line and thank me later. ✨
  • -S, --source β€” displays source code intermixed with disassembly, if possible. Implies -d. Iconic behaviour honestly. πŸ‘‘
  • --show-all-symbols β€” when disassembling, shows all the symbols that match a given address, not just the first one. Not me finally learning what was hiding behind symbol #1… 😭
  • --source-comment[=txt] β€” like the -S option, except every source code line gets displayed with a prefix of txt. Typically txt is a comment string, so you can tell the assembler code apart from the source code. If txt isn't provided, a default string of "# " (hash followed by a space) is used. πŸŽ€
  • *--prefix=prefix* β€” specify prefix to add to the absolute paths when used with -S.
  • --prefix-strip=level β€” says how many initial directory names to strip off the hardwired absolute paths. It has *no effect without --prefix=prefix*, so don't be cute. 🫢
  • --show-raw-insn β€” when disassembling instructions, prints the instruction in hex and in symbolic form. This is the default, except when --prefix-addresses is used.
  • --no-show-raw-insn β€” when disassembling instructions, does not print the instruction bytes. This is the default when --prefix-addresses is used.
  • *--insn-width=width* β€” display width bytes on a single line when disassembling instructions.
  • --visualize-jumps[=color|=extended-color|=off] β€” visualizes jumps that stay inside a function by drawing ASCII art between the start and target addresses. The optional =color argument adds color to the output using simple terminal colors. Alternatively, the =extended-color argument adds color using 8bit colors, but those might not work on all terminals. 😬

And if you ever need to kill the visualize-jumps option after it's already been enabled, use visualize-jumps=off. Periodt.

  • --disassembler-color=off
  • --disassembler-color=terminal
  • --disassembler-color=on|color|colour
  • --disassembler-color=extended|extended-color|extended-colour

Turns colored syntax highlighting in disassembly output on or off. The default behaviour is determined via a configure time option. Heads up: not all architectures support colored syntax highlighting, and depending on the terminal you're using, colored output may not actually be legible. πŸ’€

The on argument adds colors using simple terminal colors. 🌈

The terminal argument does the same, but only if the output device is a terminal.

The extended-color argument is similar to the on argument, but it uses 8-bit colors. These may not work on all terminals.

The off argument disables colored disassembly. (Sad. But valid.)

  • -W[lLiaprmfFsoORtUuTgAckK], --dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=str-offsets,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow-links] β€” displays the contents of the DWARF debug sections in the file, if any are present. Compressed debug sections get automatically decompressed (temporarily) before they're displayed. If one or more of the optional letters or words follows the switch, only those type(s) of data get dumped. ✨

The letters and words refer to the following information:

  • a, =abbrev β€” displays the contents of the .debug_abbrev section.
  • A, =addr β€” displays the contents of the .debug_addr section.
  • c, =cu_index β€” displays the contents of the .debug_cu_index and/or .debug_tu_index sections.
  • f, =frames β€” displays the raw contents of a .debug_frame section.
  • F, =frames-interp β€” displays the interpreted contents of a .debug_frame section.
  • g, =gdb_index β€” displays the contents of the .gdb_index and/or .debug_names sections.
  • i, =info β€” displays the contents of the .debug_info section. Note: the output from this option can also be restricted by the use of the --dwarf-depth and --dwarf-start options.
  • k, =links β€” displays the contents of the .gnu_debuglink, .gnu_debugaltlink and .debug_sup sections, if any of them are present. Also displays any links to separate dwarf object files (dwo), if they're specified by the DW_AT_GNU_dwo_name or DW_AT_dwo_name attributes in the .debug_info section.
  • K, =follow-links β€” displays the contents of any selected debug sections that are found in linked, separate debug info file(s). This can result in multiple versions of the same debug section being displayed if it exists in more than one file. πŸ™ˆ

On top of that, when displaying DWARF attributes, if a form is found that references the separate debug info file, then the referenced contents also get displayed. It's giving chain reaction πŸ’…

Note β€” in some distributions this option is enabled by default. It can be disabled via the N debug option. The default can be chosen when configuring the binutils via the --enable-follow-debug-links=yes or --enable-follow-debug-links=no options. If these are not used then the default is to enable the following of debug links.
Note β€” if support for the debuginfod protocol was enabled when the binutils were built, then this option also includes an attempt to contact any debuginfod servers mentioned in the DEBUGINFOD_URLS environment variable. This could take some time to resolve. 😴 This behaviour can be disabled via the =do-not-use-debuginfod debug option.
  • N, =no-follow-links β€” disables the following of links to separate debug info files.
  • D, =use-debuginfod β€” enables contacting debuginfod servers if there's a need to follow debug links. This is the default behaviour.
  • E, =do-not-use-debuginfod β€” disables contacting debuginfod servers when there's a need to follow debug links.
  • l, =rawline β€” displays the contents of the .debug_line section in a raw format.
  • L, =decodedline β€” displays the interpreted contents of the .debug_line section.
  • m, =macro β€” displays the contents of the .debug_macro and/or .debug_macinfo sections.
  • o, =loc β€” displays the contents of the .debug_loc and/or .debug_loclists sections.
  • O, =str-offsets β€” displays the contents of the .debug_str_offsets section.
  • p, =pubnames β€” displays the contents of the .debug_pubnames and/or .debug_gnu_pubnames sections.
  • r, =aranges β€” displays the contents of the .debug_aranges section.
  • R, =Ranges β€” displays the contents of the .debug_ranges and/or .debug_rnglists sections.
  • s, =str β€” displays the contents of the .debug_str, .debug_line_str and/or .debug_str_offsets sections.
  • t, =pubtype β€” displays the contents of the .debug_pubtypes and/or .debug_gnu_pubtypes sections.
  • T, =trace_aranges β€” displays the contents of the .trace_aranges section.
  • u, =trace_abbrev β€” displays the contents of the .trace_abbrev section.
  • U, =trace_info β€” displays the contents of the .trace_info section.
Heads up bestie: showing the contents of .debug_static_funcs, .debug_static_vars and debug_weaknames sections? Not supported rn. Like, the tool just doesn't do it. Sorry 😭
  • --dwarf-depth=n β€” caps how deep the dump of the .debug_info section goes: max n children. Only makes sense if you're also passing --debug-dump=info. Default vibe is "print all the DIEs, no filter"; the special value 0 for n gives you that same everything-all-at-once energy. If you give a non-zero n, DIEs at n levels deep or deeper just won't show up. And the range for n is zero-based, so mind your off-by-ones. ✨
  • --dwarf-start=n β€” only prints DIEs starting from the DIE numbered n. Again, only useful with --debug-dump=info. If you use it, it suppresses printing any header info AND every DIE before number n. Only the siblings and children of the DIE you named get printed. You can totally stack this with --dwarf-depth. 🫢
  • --dwarf-check β€” turns on extra consistency checks for Dwarf info. Paranoid queen behavior and we respect it πŸ’…
  • --debug-dir=dir β€” go search dir when you're hunting for separate debug info files.
  • --ctf[=<section>] β€” shows you the contents of the CTF section you specified. CTF sections are lowkey nested-obsessed: they contain a ton of subsections, and all of them get displayed in order. By default it shows the name of the section called .ctf, which is the name ld emits. πŸŽ€
  • --ctf-parent=<member> β€” if a CTF section has ambiguously-defined types, it's actually an archive of many CTF dictionaries, and all of them inherit from one dictionary that holds the unambiguous types. That member is by default named .ctf, same as the section containing it β€” but the name can be changed at link time using the ctf_link_set_memb_name_changer function. So when you're looking at CTF archives made by a linker that used the name changer to rename the parent archive member, --ctf-parent lets you specify the name used for the parent. King of knowing the real name πŸ‘‘
  • --ctf-parent-section=<section> β€” this one lets you pick a completely different section for the CTF parent dictionary (the one with the unambiguous types) than for the child dictionaries (the ambiguous remainder). The linker does not emit ELF objects structured like this, but some third-party linkers might. It's also handy for inspecting CTF written out as multiple raw files so you can compose them with objcopy β€” which can put them in different ELF sections, but not in different members of a single CTF dict. πŸ’€
  • --sframe[=<section>] β€” shows the contents of the SFrame section you picked. By default it displays the name of the section called .sframe, which is the name ld emits. 🌸
  • -G, --stabs β€” displays the full contents of any sections requested. It shows the contents of the .stab, .stab.index and .stab.excl sections from an ELF file. This is only useful on systems (think Solaris 2.0 era) where ".stab" debugging symbol-table entries live inside an ELF section. On most other file formats, debugging symbol-table entries are interleaved with linkage symbols, and you'll see them in the --syms output instead. Nostalgic coded. πŸ¦‹
  • --start-address=address β€” start displaying data at the specified address. This affects the output of the -d, -r and -s options.
  • --stop-address=address β€” stop displaying data at the specified address. This affects the output of the -d, -r and -s options.
  • -t, --syms β€” prints the symbol table entries of the file. Very similar to what nm gives you, except the display format is different. The format depends on the format of the file being dumped, but there are two main types. One looks like this:
        [  4](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .bss
        [  6](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 fred

where the number inside the square brackets is the number of the entry in the symbol table, the sec number is the section number, the fl value are the symbol's flag bits, the ty number is the symbol's type, the scl number is the symbol's storage class and the nx value is the number of auxiliary entries associated with the symbol. The last two fields are the symbol's value and its name.

The other common output format, usually seen with ELF based files, looks like this:

        00000000 l    d  .bss   00000000 .bss
        00000000 g       .text  00000000 fred

Here the first number is the symbol's value (sometimes called its address). The next field is actually a set of characters and spaces showing the flag bits that are set on the symbol β€” those characters are described below. Next is the section the symbol is associated with, or *ABS* if the section is absolute (i.e. not connected with any section), or *UND* if the section is referenced in the file being dumped but not defined there.

After the section name comes another field, a number, which for common symbols is the alignment and for other symbols is the size. And finally the symbol's name is displayed. πŸŽ€

The flag characters are split into 7 groups like this:

  • "l", "g", "u", "!" β€” the symbol is local (l), global (g), unique global (u), neither global nor local (a space) or both global and local (!). A symbol can be neither local nor global for a whole bunch of reasons, e.g. because it's used for debugging, but if it's ever both local and global that's probably a bug indicator. Unique global symbols are a GNU extension to the standard set of ELF symbol bindings β€” for such a symbol the dynamic linker makes sure that in the entire process there's just one symbol with this name and type in use. 🫢
  • "w" β€” the symbol is weak (w) or strong (a space).
  • "C" β€” the symbol denotes a constructor (C) or an ordinary symbol (a space).
  • "W" β€” the symbol is a warning (W) or a normal symbol (a space). A warning symbol's name is a message to be displayed if the symbol following the warning symbol is ever referenced. 😭
  • "I", "i" β€” the symbol is an indirect reference to another symbol (I), a function to be evaluated during reloc processing (i) or a normal symbol (a space).
  • "d", "D" β€” the symbol is a debugging symbol (d) or a dynamic symbol (D) or a normal symbol (a space).
  • "F", "f", "O" β€” the symbol is the name of a function (F) or a file (f) or an object (O) or just a normal symbol (a space).
  • -T, --dynamic-syms β€” prints the dynamic symbol table entries of the file. Only meaningful for dynamic objects, like certain types of shared libraries. Similar to what nm gives you when you pass it the -D (--dynamic) option. The output format is similar to what --syms produces, except an extra field gets inserted before the symbol's name, giving you the version information associated with the symbol. If the version is the default version used when resolving unversioned references to the symbol, it's displayed as is β€” otherwise it gets wrapped in parentheses. Periodt. πŸ’…
  • --special-syms β€” when displaying symbols, include the ones the target considers special in some way, the ones that would not normally be of interest to you. Surprise guests at the function ✨
  • -U [d|i|l|e|x|h], --unicode=[default|invalid|locale|escape|hex|highlight] β€” controls how UTF-8 encoded multibyte characters show up in strings. The default (--unicode=default) gives them no special treatment at all. --unicode=locale displays the sequence in the current locale, which may or may not support them. --unicode=hex and --unicode=invalid display them as hex byte sequences enclosed by either angle brackets or curly braces. --unicode=escape displays them as escape sequences (\uxxxx), and --unicode=highlight displays them as escape sequences highlighted in red (if the output device supports it). The colouring is intended to draw attention to the presence of unicode sequences where they might not be expected. It's giving "we see you, sneaky bytes" 🌈
  • -V, --version β€” prints the version number of objdump and exits. Bye bestie πŸ‘‹
  • -x, --all-headers β€” displays all available header information, including the symbol table and relocation entries. Using -x is equivalent to specifying all of -a -f -h -p -r -t. The everything-everywhere-all-at-once option, no cap. πŸ‘‘
  • -w, --wide β€” formats some lines for output devices with more than 80 columns. Also refuses to truncate symbol names when they're displayed. Long-name girlies, this one's for you πŸŽ€
  • -z, --disassemble-zeroes β€” normally the disassembly output skips blocks of zeroes. This option tells the disassembler to disassemble those blocks just like any other data. Zeroes are content too πŸ’€
  • -Z, --decompress β€” the -Z option is meant to be used in conjunction with the -s option. It instructs objdump to decompress any compressed sections before displaying their contents. (Yes, the manpage really spells it "conunction". We love her, typos and all πŸ’–)
  • @file β€” read command-line options from file. The options read get inserted in place of the original @file option. If file doesn't exist, or can't be read, then the option will be treated literally, and not removed. Options inside file are separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The file may itself contain additional @file options; any such options get processed recursively. Inception but make it CLI πŸŒ€

🌟 SEE ALSO 🌟

nm(1), readelf(1), and the Info entries for binutils. Go read the friends too, they're iconic 🫢


Copyright (c) 1991-2026 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".


And that's a wrap on the whole page, bestie πŸ’– this was binutils-2.47, dated 2026-09-12, and it lives forever under the name OBJDUMP(1). Slay, go dump some objects responsibly βœ¨πŸ‘‘

πŸ“¦ where this page comes from