LLVM-SYMBOLIZER(1)

💅 llvm-symbolizer — LLVM manual page (section 1), bestie 💅

💖 NAME 💖

llvm-symbolizer — converts addresses into source code locations. That's the whole gig. 🎯

✨ SYNOPSIS ✨

llvm-symbolizer [options] [addresses…]

🦋 DESCRIPTION 🦋

okay so bestie, here's the tea: llvm-symbolizer reads input names and addresses from the command-line and prints the corresponding source code locations to standard output. It can also symbolize logs containing Symbolizer Markup via --filter-markup. 👑

If no address is specified on the command-line, it reads the addresses from standard input. If no input name is specified on the command-line, but addresses are, or if at any time an input value is not recognized, the input is simply echoed to the output. No drama, no cap. 🫶

Input names can be specified together with the addresses either on standard input or as positional arguments on the command-line. By default, input names are interpreted as object file paths. However, prefixing a name with BUILDID: states that it is a hex build ID rather than a path. This will look up the corresponding debug binary. For consistency, prefixing a name with FILE: explicitly states that it is an object file path (the default). 💅

A positional argument or standard input value can be preceded by DATA or CODE to indicate that the address should be symbolized as data or executable code respectively. If neither is specified, CODE is assumed. DATA is symbolized as address and symbol size rather than line number. 🧚

llvm-symbolizer parses options from the environment variable LLVM_SYMBOLIZER_OPTS after parsing options from the command line. LLVM_SYMBOLIZER_OPTS is primarily useful for supplementing the command-line options when llvm-symbolizer is invoked by another program or runtime. 🌈

Lowkey important vibe check: unrecognized input values don't blow up — they're simply echoed to the output. That's the documented behavior, fr fr. 💀

---

🎀 EXAMPLES 🎀

All of the following examples use the following two source files as input. They use a mixture of C-style and C++-style linkage to illustrate how these names are printed differently (see --demangle). 😌

// test.h
extern "C" inline int foz() {
  return 1234;
}

// test.cpp
#include "test.h"
int bar=42;

int foo() {
  return bar;
}

int baz() {
  volatile int k = 42;
  return foz() + k;
}

int main() {
  return foo() + baz();
}

These files are built as follows:

$ clang -g test.cpp -o test.elf
$ clang -g -O2 test.cpp -o inlined.elf

🌸 Example 1 — addresses and object on command-line 🌸

$ llvm-symbolizer --obj=test.elf 0x4004d0 0x400490
foz
/tmp/test.h:1:0

baz()
/tmp/test.cpp:11:0

🦋 Example 2 — addresses on standard input 🦋

$ cat addr.txt
0x4004a0
0x400490
0x4004d0
$ llvm-symbolizer --obj=test.elf < addr.txt
main
/tmp/test.cpp:15:0

baz()
/tmp/test.cpp:11:0

foz
/tmp/./test.h:1:0

💜 Example 3 — object specified with address 💜

$ llvm-symbolizer "test.elf 0x400490" "FILE:inlined.elf 0x400480"
baz()
/tmp/test.cpp:11:0

foo()
/tmp/test.cpp:8:10

$ cat addr2.txt
FILE:test.elf 0x4004a0
inlined.elf 0x400480

$ llvm-symbolizer < addr2.txt
main
/tmp/test.cpp:15:0

foo()
/tmp/test.cpp:8:10

🍓 Example 4 — BUILDID and FILE prefixes 🍓

$ llvm-symbolizer "FILE:test.elf 0x400490" "DATA BUILDID:123456789abcdef 0x601028"
baz()
/tmp/test.cpp:11:0

bar
6295592 4

$ cat addr3.txt
FILE:test.elf 0x400490
DATA BUILDID:123456789abcdef 0x601028

$ llvm-symbolizer < addr3.txt
baz()
/tmp/test.cpp:11:0

bar
6295592 4

🔥 Example 5 — CODE and DATA prefixes 🔥

$ llvm-symbolizer --obj=test.elf "CODE 0x400490" "DATA 0x601028"
baz()
/tmp/test.cpp:11:0

bar
6295592 4

$ cat addr4.txt
CODE test.elf 0x4004a0
DATA inlined.elf 0x601028

$ llvm-symbolizer < addr4.txt
main
/tmp/test.cpp:15:0

bar
6295592 4

🌈 Example 6 — path-style options 🌈

This example uses the same source file as above, but the source file's full path is /tmp/foo/test.cpp and is compiled as follows. The first case shows the default absolute path, the second --basenames, and the third shows --relativenames. ✨

$ pwd
/tmp
$ clang -g foo/test.cpp -o test.elf
$ llvm-symbolizer --obj=test.elf 0x4004a0
main
/tmp/foo/test.cpp:15:0
$ llvm-symbolizer --obj=test.elf 0x4004a0 --basenames
main
test.cpp:15:0
$ llvm-symbolizer --obj=test.elf 0x4004a0 --relativenames
main
foo/test.cpp:15:0

✨ OPTIONS ✨

okay bestie, this is the part where it gets good 💅 every single flag, no skips, no cap.

• --adjust-vma <offset> — adds offset onto the object file addresses while it's doing lookups. basically you're like "pretend this object got relocated by this much" and it just… believes you. iconic of it honestly 🦋
• --basenames, -s — prints just the file's name with zero directories attached, instead of the whole absolute path. minimal queen behavior 🎀
• --build-id — looks up the object using the build ID you pass in as a hexadecimal string. heads up: this is mutually exclusive with --obj, so pick one, you can't have both 💀
• --color [=<always|auto|never>] — says whether to use color in --filter-markup mode. defaults to auto, which sniffs out whether standard output even supports color. and if you just say --color with nothing after it, that's the same as --color=always ✨
• --debuginfod, --no-debuginfod — toggles whether it bothers with debuginfod lookups for debug binaries. unless you say otherwise, debuginfod is only enabled if libcurl was compiled in (LLVM_ENABLE_CURL) and at least one server URL got provided by the environment variable DEBUGINFOD_URLS. very conditional of it 🌸
• --demangle, -C — prints demangled function names when the names are mangled (so the mangled name _Z3bazv becomes baz(), whilst the non-mangled name foz gets printed exactly as it is). defaults to true — she's demangling by default, periodt 👑
• --dwp <path> — uses the DWP file sitting at path for any CUs that have split DWARF debug data 🧚
• --fallback-debug-path <path> — when a separate file holds the debug data and it's referenced by a GNU debug link section, this is the path it uses as a basis for finding that debug data, in case it can't be found relative to the object. a little backup plan, love that for us 🫶
• --filter-markup — reads from standard input, converts the Symbolizer Markup it finds into human-readable form, and prints the results to standard output. the following markup elements are not supported yet (crying):
  • {{{hexdict}}}
  • {{{dumpfile}}}

the {{{bt}}} backtrace element reports frames using this syntax:

#<number>[.<inline>] <address> <function> <file>:<line>:<col> (<module>+<relative address>)

<inline> gives you the frame numbers for calls that got inlined into the caller coresponding to <number> (yes that's how it's spelled in the original, leaving it). the inlined call numbers start at 1 and increase from callee to caller.

<address> is an address inside the call instruction to the function. note that the address may not be the start of the instruction. <relative address> is the corresponding virtual offset in the <module> loaded at that address. iykyk 💜

• --functions [=<none|short|linkage>], -f — picks how function names get printed: omit the function name, print the short function name, or print the full linkage name respectively. defaults to linkage ⭐
• --help, -h — shows help and usage for this command. the classic 🎀
• --inlining, --inlines, -i — if a source code location is inside an inlined function, it prints all the inlined frames. this is the default, she's generous like that 💖
• --no-inlines — don't print inlined frames. simple as 😌
• --no-demangle — don't print demangled function names 🙈
• --obj <path>, --exe, -e — the path to the object file that's gonna get symbolized. if you pass -, it reads the object directly from the standard input stream. mutually exclusive with --build-id — one or the other, bestie 💀
• --output-style <LLVM|GNU|JSON> — picks your preferred output style, defaults to LLVM. when it's set to GNU, the tool follows the style of GNU's addr2line. the differences from the LLVM style are:
  • doesn't print the column of a source code location.
  • doesn't add an empty line after the report for an address.
  • doesn't replace the name of an inlined function with the name of the topmost caller when inlined frames aren't shown.
  • prints an address's debug-data discriminator when it's non-zero. one way to produce discriminators is to compile with clang's -fdebug-info-for-profiling.

JSON style gives you machine readable output in JSON. if addresses are supplied via stdin, the output JSON will be a series of individual objects. otherwise, all results will be contained in a single array. ok the receipts, look:

$ llvm-symbolizer --obj=inlined.elf 0x4004be 0x400486 -p
baz() at /tmp/test.cpp:11:18
 (inlined by) main at /tmp/test.cpp:15:0

foo() at /tmp/test.cpp:6:3

$ llvm-symbolizer --output-style=LLVM --obj=inlined.elf 0x4004be 0x400486 -p --no-inlines
main at /tmp/test.cpp:11:18

foo() at /tmp/test.cpp:6:3

$ llvm-symbolizer --output-style=GNU --obj=inlined.elf 0x4004be 0x400486 -p --no-inlines
baz() at /tmp/test.cpp:11
foo() at /tmp/test.cpp:6

$ clang -g -fdebug-info-for-profiling test.cpp -o profiling.elf
$ llvm-symbolizer --output-style=GNU --obj=profiling.elf 0x401167 -p --no-inlines
main at /tmp/test.cpp:15 (discriminator 2)

$ llvm-symbolizer --output-style=JSON --obj=inlined.elf 0x4004be 0x400486 -p
[
  {
    "Address": "0x4004be",
    "ModuleName": "inlined.elf",
    "Symbol": [
      {
        "Column": 18,
        "Discriminator": 0,
        "FileName": "/tmp/test.cpp",
        "FunctionName": "baz()",
        "Line": 11,
        "StartAddress": "0x4004be",
        "StartFileName": "/tmp/test.cpp",
        "StartLine": 9
      },
      {
        "Column": 0,
        "Discriminator": 0,
        "FileName": "/tmp/test.cpp",
        "FunctionName": "main",
        "Line": 15,
        "StartAddress": "0x4004be",
        "StartFileName": "/tmp/test.cpp",
        "StartLine": 14
      }
    ]
  },
  {
    "Address": "0x400486",
    "ModuleName": "inlined.elf",
    "Symbol": [
      {
        "Column": 3,
        "Discriminator": 0,
        "FileName": "/tmp/test.cpp",
        "FunctionName": "foo()",
        "Line": 6,
        "StartAddress": "0x400486",
        "StartFileName": "/tmp/test.cpp",
        "StartLine": 5
      }
    ]
  }
]

• --pretty-print, -p — prints human readable output. if --inlining is specified, the enclosing scope gets prefixed by (inlined by). for JSON output, this option makes the JSON indented and split over new lines — otherwise the JSON output comes out in a compact form. both are valid, one is just prettier 💅

$ llvm-symbolizer --obj=inlined.elf 0x4004be --inlining --pretty-print
baz() at /tmp/test.cpp:11:18
 (inlined by) main at /tmp/test.cpp:15:0

• --print-address, --addresses, -a — prints the address before the source code location. defaults to false 🌈

$ llvm-symbolizer --obj=inlined.elf --print-address 0x4004be
0x4004be
baz()
/tmp/test.cpp:11:18
main
/tmp/test.cpp:15:0

$ llvm-symbolizer --obj=inlined.elf 0x4004be --pretty-print --print-address
0x4004be: baz() at /tmp/test.cpp:11:18
 (inlined by) main at /tmp/test.cpp:15:0

• --print-source-context-lines <N> — prints N lines of source context for each symbolized address. chef's kiss for debugging 🔥

$ llvm-symbolizer --obj=test.elf 0x400490 --print-source-context-lines=3
baz()
/tmp/test.cpp:11:0
10  :   volatile int k = 42;
11 >:   return foz() + k;
12  : }

• --relativenames — prints the file's path relative to the compilation directory instead of the absolute path. if the command-line to the compiler included the full path, this ends up being the same as the default. no drama either way 🦋
• --verbose — prints verbose address, line and column information. she's giving detail, she's giving transparency ✨

$ llvm-symbolizer --obj=inlined.elf --verbose 0x4004be
baz()
  Filename: /tmp/test.cpp
  Function start filename: /tmp/test.cpp
  Function start line: 9
  Function start address: 0x4004b6
  Line: 11
  Column: 18
main
  Filename: /tmp/test.cpp
  Function start filename: /tmp/test.cpp
  Function start line: 14
  Function start address: 0x4004b0
  Line: 15
  Column: 18

• --version, -v — prints version information for the tool 🎀
• @<FILE> — reads command-line options from the response file <FILE>. sneaky and efficient, we love a shortcut 🧚

---

🪟 WINDOWS/PDB SPECIFIC OPTIONS 🪟

• --dia — uses the Windows DIA SDK for symbolization. if the DIA SDK isn't found, llvm-symbolizer falls back to the native implementation. it's got a plan B, main character energy 👑

---

🍎 MACH-O SPECIFIC OPTIONS 🍎

• --default-arch <arch> — if a binary contains object files for multiple architectures (like, say, it's a Mach-O universal binary), this symbolizes the object file for the given architecture. you can also name the architecture by writing binary_name:arch_name in the input (see the example below). if the architecture isn't specified either way, the address will not be symbolized. defaults to empty string 🫶

$ cat addr.txt
/tmp/mach_universal_binary:i386 0x1f84
/tmp/mach_universal_binary:x86_64 0x100000f24

$ llvm-symbolizer < addr.txt
_main
/tmp/source_i386.cc:8

_main
/tmp/source_x86_64.cc:8

• --dsym-hint <path/to/file.dSYM> — if the debug info for a binary isn't chillin' in the default location, this tells it to look for the debug info at the .dSYM path you handed over via this option. and yes, you can use this flag multiple times, stack 'em up 💜

---

🚪 EXIT STATUS 🚪

llvm-symbolizer returns 0. any other exit codes imply an internal program error — so like, if you see a non-zero, something went wrong inside the tool itself, not you, bestie 😭

---

👀 SEE ALSO 👀

llvm-addr2line(1) — go say hi 🌸

---

✍️ AUTHOR ✍️

Maintained by the LLVM Team (https://llvm.org/). they're keeping it alive, respect 💖

---

©️ COPYRIGHT ©️

2003-2023, LLVM Project 🎀

---

and that's a wrap on the whole page!! 🌈 this little run was page 15, dated 2023-07-14, and it's the LLVM-SYMBOLIZER(1) manual — go forth and symbolize, bestie, you're literally so good at this now 🫶✨