I have some compiled libraries on x86 Linux and I want to quickly determine whether they were compiled with debugging symbols.
8 Answers
The suggested command
objdump --debugging libinspected.a
objdump --debugging libinspected.so
gives me always the same result at least on Ubuntu/Linaro 4.5.2:
libinspected.a: file format elf64-x86-64
libinspected.so: file format elf64-x86-64
no matter whether the archive/shared library was built with or without -g
option
What really helped me to determine whether -g
was used is readelf tool:
readelf --debug-dump=decodedline libinspected.so
or
readelf --debug-dump=line libinspected.so
This will print out set of lines consisting of source filename, line number and address if such debug info is included into library, otherwise it'll print nothing.
You may pass whatever value you'll find necessary for --debug-dump
option instead of decodedline
.

- 1,181
- 1
- 7
- 9
-
1works perfectly. I tried this command on my executable with first CMAKE_BUILD_TYPE RELEASE and the command returned empty. Then I tried with CMAKE_BUILD_TYPE DEBUG and then there were quite a lot of output. – infoclogged Aug 22 '17 at 15:56
If you're running on Linux, use objdump --debugging
. There should be an entry for each object file in the library. For object files without debugging symbols, you'll see something like:
objdump --debugging libvoidincr.a
In archive libvoidincr.a:
voidincr.o: file format elf64-x86-64
If there are debugging symbols, the output will be much more verbose.

- 8,084
- 8
- 48
- 62

- 1,639
- 1
- 10
- 12
-
6There are also `obdjump -W lib` and `readelf -w lib`. The latter one is more configurable - see readelf(1) manpage. – przemoc Jan 04 '10 at 14:16
-
4For any binary, (including those compiled with -g) objdump gives me the response of "no recognized debugging information" unless I compile it with -gstabs. This appears to be a recognized bug. – Dan Hook Jan 04 '10 at 14:24
-
-
Employed Russian: from man objdump(1), the --debugging flag "attempts to parse STABS and IEEE debugging format information stored in the file and print it out using a C like syntax. If neither of these formats are found this option falls back on the -W option to print any DWARF information in the file." – Matt McClellan Jan 05 '10 at 17:13
-
5`objdump -g` gives me nothing for a simple test.o compiled both with and without `g`, making it effectively useless. Ubuntu 12.04, gcc 4.6.3, GNU objdump 2.22. `nm -a` seems to be more useful. – jw013 Sep 20 '13 at 13:49
-
-
When testing on linux shared library (*.so), it produces lot's of output on without debugging symbols. `nm -a` looks more reliable. – pevik Oct 09 '15 at 09:39
What helped is:
gdb mylib.so
It prints when debug symbols are not found:
Reading symbols from mylib.so...(no debugging symbols found)...done.
Or when found:
Reading symbols from mylib.so...done.
None of earlier answers were giving meaningful results for me: libs without debug symbols were giving lots of output, etc.

- 7,067
- 6
- 43
- 87
-
Thx! This worked for me, using clang compiler in Android with cmake :) – Pär Nils Amsen May 26 '17 at 10:56
-
super great for a fast checking ! also works on *.o object files. – Stephane Rolland Jun 13 '20 at 18:58
nm -a <lib>
will print all symbols from library, including debug ones.
So you can compare the outputs of nm <lib>
and nm -a <lib>
- if they differ, your lib contains some debug symbols.

- 34,062
- 14
- 56
- 86
-
3@Employed Russian Can you please elaborate on this? Why do you think it is a wrong tool? It does the job, and does it on Linux as well. – qrdl Jan 05 '10 at 08:27
-
Even for Embedded linux based on kernel 2.6.35, xxx-objdump, xxx-nm works fine. – agfe2 May 22 '14 at 11:44
-
-
3
On OSX you can use dsymutil -s
and dwarfdump
.
Using dsymutil -s <lib_file> | more
you will see source file paths in files that have debug symbols, but only the function names otherwise.

- 2,069
- 2
- 26
- 37
-
15Can you provide an elaboration on what to look for in the output of, for example, `dsymutil -s`? Does the existence of output mean that it was built with debug symbols, or should it be grepped? – Mitch Jan 22 '16 at 10:45
You can use objdump for this.
EDIT: From the man-page:
-W
--dwarf
Displays the contents of the DWARF debug sections in the file, if
any are present.

- 4,046
- 1
- 26
- 45
-
1Doesn't work with macOS's LLDB `objdump`: `error: unknown argument '--dwarf'` – Boris Verkhovskiy Apr 04 '23 at 09:28
Answers suggesting the use of objdump --debugging
or readelf --debug-dump=...
don't work in the case that debug information is stored in a file separate from the binary, i.e. the binary contains a debug link section. Perhaps one could call that a bug in readelf
.
The following code should handle this correctly:
# Test whether debug information is available for a given binary
has_debug_info() {
readelf -S "$1" | grep -q " \(.debug_info\)\|\(.gnu_debuglink\) "
}
See Separate Debug Files in the GDB manual for more information.

- 7,356
- 2
- 25
- 20
-
So, `readelf -S example | grep debug` would be better. To find link file using `readelf --debug-dump=links example | grep link` (GNU readelf version 2.31.1-13.fc29) – Nick Dong Aug 10 '21 at 13:46
The command readelf -wi file is a good verification of debuginfo, compiled within your program.