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.
Related
I'm trying to compile the module in Eclipse and generate the additional output disassembles
I've added these Tool Flags
-fverbose-asm -Wa,-adhln -save-temps=obj > %OutFile%.asm
But I receive this error
clang: error: unsupported argument '-adhln' to option 'Wa,'
Does anybody had a similar issue? If so please help
Many Thanks
OK so the target was to generate the assemblies with the instructions HEX and relative addresses
I was not able to do that using Eclipse >> Tool Flags so I simply left one flag:
-save-temps=obj
Which generates AT&T systax assemblies but without details like (instruction Hex or relative address)
But I've managed to generate INTEL syntax assemblies with all the details I need to debug my problem using objdump
objdump -d -M intel -S DMAProcesor.o > DMAProcessor.asm
I've configured and built gpreftools. however, I can't seem to find the generated profile file of my program to display it.
I took the following actions:
Adding the -lprofiler linker flag to my .pro, building the program and the flag is added correctly at the linking stage.
QMAKE_LFLAGS += -lprofiler
Running with:
$ CPUPROFILE=/tmp/prof.out /path/to/executable
Executing:
$ pprof --gv /path/to/MyExe /tmp/prof.out
Then I get the following:
Failed to get profile: curl -s --max-time 90 'http:///pprof/profile?seconds=30' > /home/eslam/pprof/.tmp.MyExe.1509005857.: No such file or directory.
Anyone has a resolve on this?
Check that your program actually links to libprofiler.so. Some OSes (e.g. AFAIK some versions of ubuntu) do not actually add .so if none of it's symbols are actually used. E.g. ldd ./yourprogram should list libprofiler.so. If this does not happen, then you should prepend something like -Wl,--no-as-needed to your linker flags.
LD_PRELOAD method without rebuild
Besides passing -Wl,--no-as-needed,-lprofiler,--as-needed at build time mentioned by Eslam, you can also get it to work without modifying the build by passing the LD_PRELOAD option at runtime as:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libprofiler.so CPUPROFILE=prof.out ./main.out
You can find libprofiler.so easily with locate libprofiler.so.
See also: How can I profile C++ code running on Linux?
Tested in Ubuntu 18.04.
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 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.
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