I complied my program with only -g option, and add some libs like -lpthread
But when I use gdb to debug my program, using step it will step into some system functions, like fork and memcpy.
Is there a way to avoid that? It happens after I install valgrind on my computer.
Kernel:2.6.38-13
You need to run the following from a gdb prompt..
(gdb) set auto-solib-add off
It prevents gdb from loading symbols from libraries.
Related
Using gdb 7.12-6 - (on debian linux in a virtualbox) I have the problems described below using step
strangely using gdb 7.4.1-debian everything seems to be fine and there are no issues (debian linux in an older virtualbox on a different computer)
I am trying to step through code. I don't want to use next because I want to go into the subroutines I have written.
I am having a problem with it going into malloc.c, s_sin.c and a whole host of other library routines.
I have checked that step-mode is off
I have tried using skip /usr/include/*, skip /usr/include/*/*, skip /usr/include/*/*/*
I already looked at the questions below and didn't find the answer to my question
Preventing GDB from stepping into a function (or file)
gdb - skip further step in of certain file by predefined rule?
Any help would be much appreciated
[I am compiling with gcc -g -o program program.c -lm]
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.
I have downloaded the source of GMP library 5.02, and - as suggested here for maximum debuggability - I ran :
./configure --disable-shared --enable-assert --enable-alloca=debug --host=none CFLAGS=-g
and compiled it with make, then installed the library with make install. I then compiled my program like this: gcc -lgmp -std=c99 -g -c program.c and then I ran : ltrace ./a.out
However I realized that ltrace is not at all invoking the TRACE() functions I can find in the source code. I would like to trace the content that's in TRACE().
How should I go for that? Or is there any other straightforward way of debugging inside the GMP library? (I couldn't figure it out how to do it with gdb, it never wanted to step into gmp_printf)
Thanks.
EDIT:
I tried to investigate further, and realized that I couldn't modify the GMP library although I had the sources. I inserted a printf("hello\n"); at the very beginning of the mpz_init2 function which I do call at the beginning of my program, I recompiled all GMP (even after a make clean) re-installed the library with make install, then I compiled and launched my program, but it never printed "hello". I also made sure, I wasn't using another installed GMP library (when I do make uninstall my program cannot compile as it does not find the library). Still, I insisted that gcc looks for the library in the GMP source folder with the -L option.
I don't know what I'm doing wrong :(
Your final compile of a.out is not producing a statically linked a.out executable. So, even though as you state, during compilation of program.c the compiler is using your GMP library, at runtime it is picking up a shared library somewhere. You need to do one of two things:
Compile with -Bstatic (or something similar; check man page for your compiler)
Set the LD_LIBRARY_PATH (or something similar; check 'ld' or 'dyld' man pages)
I think #1 is actually your only choice given that you built only the static version of GMP. For #1 make sure you explicitly provide -L/path/to/gmplib in the compilation of program.c
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..)