LLVM-SYMBOLIZER(1)
π NAME π
Okay bestie, this is llvm-symbolizer(1) from LLVM β the literal icon whose whole job is to convert addresses into source code locations. That's it, that's the name, main character energy only. π
β¨
β¨ SYNOPSIS β¨
llvm-symbolizer [options] [addresses...]
π DESCRIPTION π
So 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. Addresses may be specified as numbers or symbol names. No cap. π«Ά
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, the first address value is treated as an input name. If an input value is not recognized, it reports that source information is not found.
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. Periodt. π
bestie note: if an input value doesn't get recognized, it reports that source information is not found β no guessing, no invented lore. π
πΈ 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. Iykyk, path vibes are real. π¦
$ 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
Example 7 β Addresses as symbol names
$ llvm-symbolizer --obj=test.elf main
main
/tmp/test.cpp:14:0
$ llvm-symbolizer --obj=test.elf "CODE foz"
foz
/tmp/test.h:1:0
β¨ OPTIONS β¨
okay bestie, this is the part where the tool gets customized. every single flag is here, no skips, we're doing the whole runway π
--adjust-vma <offset>β adds that offset to object file addresses when it's doing lookups. it's giving "pretend this object got relocated by the offset" energy, so you can look stuff up as if it had been. β¨--basenames,-sβ prints just the file's name with zero directories, instead of the absolute path. clean, minimal, lowkey iconic π--build-idβ look up the object using the build ID you give it, specified as a hexadecimal string. heads up: it's mutually exclusive with--obj, so pick one, bestie, you can't have both π«Ά--color [=<always|auto|never>]β says whether to use color in--filter-markupmode. defaults toauto, which detects whether standard output supports color. and yeah, specifying--colorall by itself is equivalent to--color=alwaysπ--debug-file-directory <path>β gives a path to a directory that has a.build-idsubdirectory, so we can search for debug information for stripped binaries. if you pass this multiple times, the instances get searched in the order you gave them π--debuginfod,--no-debuginfodβ whether or not to try debuginfod lookups for debug binaries. unless you specify otherwise, debuginfod is only enabled if libcurl was compiled in (LLVM_ENABLE_CURL) and at least one server URL was provided by the environment variableDEBUGINFOD_URLSπ¦--demangle,-Cβ prints demangled function names, if the names are mangled. like, the mangled name_Z3bazvbecomesbaz(), whilst the non-mangled namefozis printed as is. defaults to true, so yeah, it's already slaying β¨--dwp <path>β uses the DWP file at<path>for any CUs that have split DWARF debug data π¦--fallback-debug-path <path>β when a separate file contains debug data and it's referenced by a GNU debug link section, this path is used as a basis for locating the debug data if it can't be found relative to the object. backup plan vibes π--filter-markupβ reads from standard input, converts the contained Symbolizer Markup <> into human-readable form, and prints the results to standard output. but ngl, the following markup elements are not yet supported:{{{hexdict}}}{{{dumpfile}}}
the {{{bt}}} backtrace element reports frames using this syntax:
#<number>[.<inline>] <address> <function> <file>:<line>:<col> (<module>+<relative address>)
<inline> provides frame numbers for calls inlined into the caller corresponding to <number>. the inlined call numbers start at 1 and increase from callee to caller. π₯
<address> is an address inside the call instruction to the function. heads up: the address may not be the start of the instruction. <relative address> is the corresponding virtual offset in the <module> loaded at that address. no cap π
--functions [=<none|short|linkage>],-fβ specifies the way function names get printed: omit the function name, print the short function name, or print the full linkage name, respectively. defaults tolinkageπ--help,-hβ shows help and usage for this command. bestie behavior honestly π«Ά--inlining,--inlines,-iβ if a source code location is in an inlined function, it prints all the inlined frames. and yeah, this is the default, we love a generous queen πΈ--no-inlinesβ don't print inlined frames. simple as that π--no-demangleβ don't print demangled function names. the raw mangle stays raw π--obj <path>,--exe,-eβ path to the object file to be symbolized. if you specify-, it reads the object directly from the standard input stream. mutually exclusive with--build-idβ again, one or the other, babe π--output-style <LLVM|GNU|JSON>β specifies the preferred output style, defaulting toLLVM. when the output style is set toGNU, the tool follows the style of GNU'saddr2line. the differences from the LLVM style are:- it does not print the column of a source code location
- it does not add an empty line after the report for an address
- it does not replace the name of an inlined function with the name of the topmost caller when inlined frames are not shown
- it 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
and JSON style provides a 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. β
$ 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--inliningis 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 is printed in a compact form. cute and functional π
$ 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. it's giving "show me around the neighborhood" π‘
$ 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 will be the same as the default. so sometimes it changes nothing, and that's fine π¦--verboseβ prints verbose address, line and column information. every last crumb π
$ 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>. yes, a whole file of options, very main character π
πͺ WINDOWS/PDB SPECIFIC OPTIONS πͺ
--diaβ uses the Windows DIA SDK for symbolization. if the DIA SDK isn't found,llvm-symbolizerwill fall back to the native implementation. no drama, it just switches β¨
π MACH-O SPECIFIC OPTIONS π
--default-arch <arch>β if a binary contains object files for multiple architectures (like, it's a Mach-O universal binary), symbolize the object file for a given architecture. you can also specify the architecture by writingbinary_name:arch_namein the input (see the example below, bestie). 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 present in the default location, look for it at the.dSYMpath you provide via this option. and yes, this flag can be used multiple times, stack 'em π«Ά
π¦ EXIT STATUS π¦
llvm-symbolizer returns 0. any other exit codes imply an internal program error. so if you see something that isn't 0, that's not a vibe β that's a bug π
π SEE ALSO π
llvm-addr2line(1) <llvm-addr2line.html> β go read that one too, iykyk π
Author
Maintained by the LLVM Team (https://llvm.org/). give them their flowers π
Copyright
2003-2026, LLVM Project
and that's the whole page, bestie β this one's from LLVM-SYMBOLIZER(1), dated 2026-09-09, and the manpage footer source/version line is literally just that same LLVM-SYMBOLIZER(1) tag. slay, go symbolize something π¦π
π¦ where this page comes from
- ubuntu stonking: llvm-18 1:18.1.8-20ubuntu11 Β· APACHE-2-LLVM-EXCEPTIONS
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms