I made my code as a standalone .c file and read that, in order to debug, the file must be in a project. So I made an empty project and added my file to it, set some breakpoints and, when i run the debugger, I get this on console:
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.6.1
Child process PID: 13112
Error in re-setting breakpoint 2: PC register is not available
Error in re-setting breakpoint -3: PC register is not available
In ()
Tried some tutorials and whatched some videos without success. Does somebody knows a fix for that? Is there a simpler way to debug a .c file?
For linux system you could use gdb as debugger in this way:
$ vim hello.c
# include <stdio.h>
int main()
{
printf("hello \n");
}
$ gcc -o hello hello.c
$ ./hello
$ gdb hello
(gdb) break main
(gdb) run
and then you can use:
c or continue
n or next
s or step
For more details see this.
Updated MinGW downloading it from its sourceforge repositor.
Downloaded the 6.2.0 version that is available in this link.
Then I unziped it to C:\ and modified the environment variable Path to add the new C:\MinGW\bin folder. To know if you made it correctly just open CMD and type gcc --version.
After that, I modified the compiller and debugger settings of Code::Blocks to use the new version of MinGW and its executables.
Now it is compiling and debugging properly.
According to Free Pascal's GDB Debugger Tips the problem is with GDB and they cite Bug 14018.
It appears you should use a different version of GDB. They suggest downgrading to 7.2. Now I believe other versions are now available, like 8.0. I don't know if GDB 8.0 suffers it too.
Related
I am new to coding and trying to get eclipse neon running on my macbook air. I am having trouble getting the debugger to work. I installed gdb with homebrew, created a certificate and signed gdb as per the instructions in the link:
https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html
I then configured eclipse debugger settings with the location of the newly installed gdb. However now when I try to start the debugger, the initialization process starts but gets stuck forever on 62%. Any tips on how to solve this? Could it be a memory issue? MBA has 4gb RAM...
This is a known bug in CDT - Bug #509737
The problem in summary is that CDT version 9.2.0 cannot work with GDB version 7.12.
One way to resolve this is to use an older version of GDB, for example GDB version 7.11
Another way to workaround this is to pretend GDB 7.12 is actually version 7.11.
Create the following executable script:
#!/bin/sh
if [ "$1" = "--version" ]; then
echo "GNU gdb (Debian 7.11-1) 7.11"
exit
fi
exec /usr/local/bin/gdb "$#"
and configure eclipse to run it instead of gdb.
I try to debug some native code on Android with GBD. The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool. I use gdbserver on the android machine and connect to it from my mac with the normal GDB program. I try to load all the libraries (which should have symbols according to objdump tool), but gdb tells me that it does not load the symbols (according to the gdb command “info sharedLibrary”). These are the steps I took:
start gdbserver on Android machine
start GDB with the debug version of the binary
gdb symbols/system/bin/mediaserver
the following commands are executed in gdb itself
tell gdb where to look for the libraries with symbols
(gdb) set solib-search-path symbols/system/lib
tell gdb where to find the source files
(gdb) directory /sources
connect to remote target (Android machine)
(gdb) target remote 192.168.1.10:5039
GDB connects successfully to the running binary and I can pause and continue the execution. But it does not show me any debug information like function names or line numbers. It only shows adresses. When I check the status of the used libraries, I see that gdb thinks, they don’t have any symbols:
command in gdb:
(gdb) info sharedLibrary
From To Syms Read Shared Object Library
0x00003700 0x0000ff0c Yes /symbols/system/bin/linker
No libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libspeexresampler.so
No libaudioutils.so
No libgccdemangle.so
No libamplayer.so
Now for example the last library. When I check with the file command (not in gdb), it tells me that it is a not stripped library (the library is located in the "symbols/system/lib" folder).
file libamplayer.so
Output:
libamplayer.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
objdump command shows a lot of symbols in it (I don’t show the output because it’s very long). So why does gdb not recognise the symbols in this libraries? I thought, at least line numbers and function names are present in not stripped versions of libraries. Or am I wrong? It would be very nice if someone could give me more insight.
Thanks!
System info:
GDB Version: 7.3.1-gg2 on Mac OS X Mavericks
The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool.
Your conclusion does not at all follow. ndk-gdb should be able to debug any Android program, whether created as a "project" or via other means.
I use gdbserver on the android machine and connect to it from my mac with the normal GDB program.
The normal GDB is likely not configured for cross-debugging, and thus doesn't understand ARM binaries at all. I am surprised you get as far using it as you do.
Maybe I'm missing something obvious since I searched the internet for quite a while but could not find a solution for the following problem:
I'm using Eclipse Kepler SP2 (Build id: 20140224-0627) with CDT and MinGW as compiler backend. Debugging C code with gdb worked great up until today (at least I noticed the problem today).
Now I get the following error message when i want to start a progam in the debugger:
Error in final launch sequence
Failed to execute MI command:
-file-exec-and-symbols C:/[...]/Debug/test.exe
Error message from debugger back end:
"C:\[...]\Debug\test.exe": not in executable format: File format not recognized
The program runs nicely and so I thought I might have screwed up some settings. But when I tried to debug an old program, everything worked until I recomplied the old program -> same problem. If I ask the C-wizard to create a new "Hello World" ANSI C application with MinGW, the same problem occurs.
The compile commands which were used are
gcc -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\test.o" "..\\src\\test.c"
gcc -o test.exe "src\\test.o"
I did not update my MinGW in between, but updated Eclipse.
Do you have any pointers on where to look for the problem?
Edit: I just checked the binary type: My old projects are all [x86/le], the newly compiled ones are [amd64/le]. This should be a trace.... Will update posting according to progress.
Edit2: argh I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
I'll post this as answer, too. Heading and tags have been updated to point to this issue more directly.
I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
BTW: This happened, because strawberry added c:\strawberry\c to the PATH in front of my custom c:\MinGW and eclipse adds those to the BUILD SYSTEM variables.
It should be a parser problem, what is your binary parser under Project/Properties/Build/Settings ?
Check Project->Properties ->C/C++ Build ->environment and path for MINGW_HOME
make sure you have right gdb version (by checking under debug Configuration ->environment).
I am asked to debug a C code containing a number of .c files and is complied using a Makefile on a Redhat Linux system. I want to debug that whole code. How to go about it? What changes do i need to make in the Makefile?
I am using gcc as the compiler.
If you're using GCC as compiler add to the CFLAGS variable the -g option. Then you'll be able to debug the resulting executable using the gdb command.
First you need to add the flag "-g" during compilation(make this change in the makefile.if already present then no need). this will open up the symbols for debugging the code.
use the debugging tools available like gdb, dbx, mdb which ever is available in your system.
many resources are available for debugging. one of them is here
Add -g option in your makefile in order to invoke gdb debugger in the future.The way you debug on gdb is like : gdb yourprogram,then you will be redirected to another interface.type "run yourarguments" to start off debugging
I just started learning C, and I am looking for a simple tool for debugging in gcc environment. Such tool would print a stack trace, and indicate where a segmentation fault occurs.
Try gdb; or a frontend like ddd or kdgb.
Compile with the -g flag.
GDB does it all - you need to compile your program with debug information (use -g switch) and then open it with GDB. To print stack trace use command bt.
To investigate segfaults you need to pass path to core file to GDB as well, like this:
gdb yourprogram core
If your system by default doesn't generate core files in case of segfault, you can switch it on using command:
ulimit -c unlimited
GDB is what you are looking for. In particular, the backtrace command in GDB will show you a stack trace. http://www.cs.cmu.edu/~gilpin/tutorial/
If you use X try "ddd"
Whether you use the command line gdb, or one of the front-ends such as DDD, you should definitely take a look at the gdb manual, which is also (like many GNU manuals) a very good tutorial.
I would also advise to look at valgrind.
There's also a nice integration of gdb in kdevelop (the emacs binding is fine too..)