I want to use gdb to debug the code. When I write the command:
gdb gdns_processor
It will output the warning message from gdb:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/gdnscenter/bin/gdns_processor...
warning: the debug information found in "/usr/lib/debug//usr/local/gdnscenter/bin/gdns_processor.debug" does not match "/usr/local/gdnscenter/bin/gdns_processor" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/local/gdnscenter/bin/gdns_processor.debug" does not match "/usr/local/gdnscenter/bin/gdns_processor" (CRC mismatch).
(no debugging symbols found)...done.
I don't understand CRC mismatch. Why gdb can't find symbols?
PS: My gcc options have set -g flag.
CPPFLAGS="-D_LIBC_REENTRANT $CPPFLAGS -g"
I don't understand CRC mismatch
To understand the message, you need to read about GDBs use of "separate debug files", e.g. here.
my Gcc options have set -g. CPPFLAGS="-D_LIBC_REENTRANT $CPPFLAGS -g"
It is likely you are not telling us the whole story. Your build procedure probably produces the gdns_processor binary, and the gdns_processor.debug "separate debug file" for it.
You then copy the gdns_processor to /usr/local/gdnsceter/bin/, but (apparently) neglect to copy gdns_processor.debug into /usr/lib/debug/usr/local/gdnscenter/bin/.
maybe the program you debugging mismatch the source code, considering recompile the program. PS: if you want more detail of the debug information, you can use -ggdb option.
Related
I created a Hello World example in C++ and tried to debug it with lldb from the terminal on Mac OSX.
> lldb a.out
Current executable set to 'a.out' (x86_64).
I can set breakpoints on names (eg. 'main'), but not on line numbers. If I try
breakpoint set --file test.c --line 5
or
b test.c:5
I get
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
The file 'test.c' is located in the current folder. What goes wrong?
Acording to Dwarf Debugging Information Format, the line number, file location information are stored in the Dwarf format. Such information is what GDB used to set line number as a breakpoint.
Usually, the Dwarf format information is generated by compiler, such as GCC with the -g options. Please try with -g options to see whether it works.
Meanwhile, there also some other debug helpful options in GCC which might be more helpful to you, such as -g3, compiler will generate more detail information for debug, such as macros.
I have a file called test. Even after compiling it with -g, when I run it in gdb, it says no debugging symbols found. I have also tried using -ggdb but it too was off no use. Please help.
Output for : gdb test
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/test...(no debugging symbols found)...done.
The issue is that you are attempting to debug the wrong program.
Your program is called test and yet you are debugging /usr/bin/test (a system program that will almost certainly be shipped without symbols; even if it did contain symbols, they wouldn't relate to your source code).
gdb will search $PATH to find the executable. From here:
exec-file [ filename ] Specify that the program to be run (but not the
symbol table) is found in filename. gdb searches the environment
variable PATH if necessary to locate your program. Omitting filename
means to discard information on the executable file.
Try using the command:
$ gdb ./test
Remove a.out and then try again. It worked for me as I was also getting the same error.
rm a.out
gcc -g your_code.c
Check that the executable is not stripped, you can see that with file /usr/bin/test
I'm trying to debug my first program in D compiled using
dmd -debug hello.d
but when I run the executable through GDB-7.6 it doesn't seem to know where to find the source code and decode the format of the stack trace (and its name-demangling).
Is GDB-debugging DMD-generated executables not yet supported or have I missed something?
The -debug flag means that debug code is enabled, which is not the same as having debug symbols. The flag you are looking for is -g or -gc.
See http://dlang.org/dmd-linux.html#switches for more info on the compiler flags.
I'm developing on an ARM9E processor running Linux. Sometimes my application crashes with the following message :
[ 142.410000] Alignment trap: rtspserverd (996) PC=0x4034f61c
Instr=0xe591300c Address=0x0000000d FSR 0x001
How can I translate the PC address to actual source code? In other words, how can I make sense out of this message?
With objdump. Dump your executable, then search for 4034f61c:.
The -x, --disassemble, and -l options are particularly useful.
You can turn on listings in the compiler and tell the linker to produce a map file. The map file will give you the meaning of the absolute addresses up to the function where the problem occurs, while the listing will help you pinpoint the exact location of the exception within the function.
For example in gcc you can do
gcc -Wa,-a,-ad -c foo.c > foo.lst
to produce a listing in the file foo.lst.
-Wa, sends the following options to the assembler (gas).
-a tells gas to produce a listing on standard output.
-ad tells gas to omit debug directives, which would otherwise add a lot of clutter.
The option for the GNU linker to produce a map file is -M or --print-map. If you link with gcc you need to pass the option to the linker with an option starting with -Wl,, for example -Wl,-M.
Alternatively you could also run your application in the debugger (e.g. gdb) and look at the stack dump after the crash with the bt command.
I've configure all CONFIG_DEBUG_ related options to y,but when I try to debug the kernel,it says no debug symbols found:
gdb /usr/src/linux-2.6.32.9/vmlinux /proc/kcore
Reading symbols from /usr/src/linux-2.6.32.9/vmlinux...(no debugging symbols found)...done.
Why?
Here is my best guess so far: I don't know, and it doesn't matter.
I don't know why GDB is printing the message "(no debugging symbols found)". I've actually seen this when building my own kernels. I configure a kernel to use debug symbols, but GDB still prints this message when it looks at the kernel image. I never bothered to look into it, because my image can still be debugged fine. Despite the message, GDB can still disassemble functions, add breakpoints, look up symbols, and single-step through functions. I never noticed a lack of debugging functionality. I'm guessing that the same thing is happening to you.
Edit: Based on the your comments to the question, it looks like you were searching for the wrong symbol with your debugger. System call handlers start with a prefix of sys_, but you can't tell from looking at the code. The macro SYSCALL_DEFINE4(ptrace, ...) just ends up declaring the function as asmlinkage long sys_ptrace(...), although it does some other crazy stuff if you have ftrace enabled.
make menuconfig->kernel hacking->[]Kernel debugging->[]Compile the kernel with debug info(CONFIG_DEBUG_INFO)
It's also possible when you package your vmlinuz image, the debug symbols were stripped (when using make-kpkg to build deb package for linux kernel). So you have to use the built vmlinux file under your linux source tree to have those debug symbols.
Add -g to the CFLAGS variable in the kernel Makefile
I might be wrong, but I thought you would have to install the debuginfo package for your kernel to get symbols