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
Related
I'm trying to figure out how to debug core files sent to me from my released versions of software (c code compiled with gcc).
I have a debug version (compiled with -g) of the executable, can I debug it?
Or is there a way to map between files to help with the debugging process.
I have a debug version (compiled with -g) of the executable, can I debug it?
No. The debug build will have different addresses for all the symbols, and GDB needs the correct mapping of symbols to code.
IF you compiled the binary with GCC, you may be able to rebuild it with all the original release flags and -g. The resulting executable may be close enough, though there are no guarantees.
Note: this currently doesn't currently work for Clang.
The best practice is to compile the binary with -O2 (or whatever optimization you are using) and -g together, then strip -g a.out -o a.out.release and ship the a.out.release binary, while keeping the full-debug a.out for future debugging.
That way you guarantee that all the symbol addresses are identical between the released executable and your full-debug copy.
P.S. There are ways to automate finding correct full-debug copy for any given released binary, making it easier to be sure that the correct full-debug file is loaded for any given released binary.
I have large C project which I'm compiling manually and then debugging via GDB.
I'm already editing source in Eclipse, but I am not able to compile it there, because of complex and multiple makefile.
Is it possible only to launch app via Eclipse for debugging as via GDB?
Thanks
Yes, you can just set up the debugger to point to the binary and have it launch it. Just make sure you compile it with the right flags (-ggdb and -g3 for symbols). If you have it imported as a Makefile project, it should be able to automatically map your code to the symbols.
Basic instructions are here: http://eclipse.org/jetty/documentation/current/debugging-with-eclipse.html
I would like to know how I can prevent gcc under Cygwin from automatically adding the .exe extension to compiled files, because I just caused myself a lot of confusion with "missing files". For context, I am working on a C project for university and I usually work in the labs which run Ubuntu (dual-boot with Windows), but to work from home I prefer using my Windows machine, ergo Cygwin. If I just remove the extension it still works just fine on either system, but it is rather frustrating to have to change the command to include the extension whenever I've just compiled it under Cygwin.
I looked up the FAQ from Cygwin to find that it is probably an issue related to an environment variable in .bashrc or .bash_profile (see here), but I am no command-line ninja and am not very familiar with editing configuration files... I found two related questions as well that show the same behaviour, but have nothing to do with trying to change it:
Compiling with gcc (cygwin on windows)
Executable file generated using gcc under cygwin
Any ideas?
It is actually for an MPI in C project so I have a Makefile that calls mpicc but that is not really relevant to the problem, since I just tried with gcc as well and both do the same thing. For the purpose of this question, the commands and outputs I get are:
$ gcc -o hello hello.c
$ ls
hello.c hello.exe
$./hello
Hello, world!
$./hello.exe
Hello, world!
Note that running with or without the extension does the same thing in the shell, but it does not with mpirun which is why I want to change this behaviour.
I eventually decided that Windows is not the programming environment for me. From now on all work that can be done in Linux will be.
7 years and no one to tell ?
My answer : Yes it's possible to produce an executable without .exe extension under Cygwin GCC. By telling the linker how to name its output.
$ echo -e "#include <stdio.h>\nint main(int nbargs, char *args[]) {
printf(\"Hello \\\n\");
}" | gcc -pipe -x c - -Wl,-oess2
This will produce an ess PE32 / PE32+ executable file, not a ess.exe.
The -pipe option instructs the GCC build chain to not write temporary files but use pipe between stages instead. The -Wl,-o option inhibits the default --force-exe-suffix.
And this way you can really nullify Cygwin GCC output with -Wl,-o/dev/null, the linker will fail when trying to close the output but you can trap the error message. If you get it, you can be assured that GCC reaches the link stage far enough to produce an output, which means that GCC can build an executable with this code.
From the ld man page :
--noinhibit-exec Retain the executable output file whenever it is still usable. Normally, the linker will not produce an output file if
it encounters errors during the link process; it exits without writing
an output file when it issues any error whatsoever.
DO NOT USE -Wl,-o/dev/stdout under Cygwin. Under Cygwin, /dev/stdout is a symlink, and if the linker fails it will DELETE /dev/stdout.
On the other end, -Wl,-o/proc/self/fd/1 will do no harm, but the linker will fail and will produce only an error message on stdout. Currently, it seems there is no direct way under Cygwin to pipe the linker output, even with named pipes.
The automatic exe extension for executables is there for a reason (Windows requires it). You should deconfuse (aka educate :-) yourself and accept the way Cygwin works. This is a feature rooted so deeply in the Cygwin/Windows guts that it is almost impossible to make it run without it.
For a "Unix feeling on Windows" with a different approach you want to check out AT&T's UWin.
I am trying to run a MPI program with C language.
I have installed GCC compiler and the openmpi libraries. I am running ubuntu Linux and Netbeans IDE. My challenge is that after including ‘mpi.h’ in my header file and compiling the application, I still get ‘fatal error : cannot find file mpi.c’. I have the files in home/user/lib/openmpi/include, but I cant get it too work.
Can anyone help?
You could try to change the compiler to /path/mpicc and the debugger to mpirun. This should work, although I did not test it, but probably the best way to compile MPI code is via terminal.
If you really depend on the IDE you cound try writing your code with it (to take advantage of auto-completion and such) and compile it in terminal using mpicc -o main.exe main.cpp [other .cpp files] and run it with mpirun -np number_of_processes_to_use ./main.exe [args]. You could write a small script or a Makefile to do it all in one command.
Good luck!
to save yourself some sanity, I'd recommend opening up a terminal and going from there (at least until you figure out what's what).
Also, using the mpi compiler to do things would simplify your life. (and likely automatically solve the missing source issue, as it should know where they are by default).
If you still can't locate them during compile then I'd look at adding the location where mpi.c & mpi.h are located to your C Include Path: How to add a default include path for gcc in linux?
I'm currently building on Windows 7 and am trying to get my debugger to step through my code. The problem is that, while I have my build configuration set to debug, and my CONFIG variable to set to debug in my QMake file, it still doesn't work.
Here is my QMake file:
TEMPLATE = app
CONFIG += console debug
CONFIG -= qt
QMAKE_CXXFLAGS += -g -gdb
SOURCES += main.c \
Triangle.c \
GlutTesting.c
HEADERS += \
Triangle.h \
Includes.h \
GlutTesting.h
LIBS += -lSDL -lopengl32 -lfreeglut
Note that it's actually written in C and compiled as such (all of the files are native C code, compiled with MinGW).
The issue is that everytime I start, even if I set a breakpoint, the code literally just zooms through it to the end of the applications current setting and stops there. It's almost impossible to actually debug my applications now.
What is wrong here? Everytime I Google I just find something about "adding debugging symbols", which is easy to do in Linux, but in Qt Creator it seems quite the PITA to get done properly (unless I'm just missing something totally simple).
Faced the similar problem on Linux (Fedora 16) using Qt Creator 2.5.0
It turned out that gdb started in my home directory and could not (I don't know why) load debugging symbols of a library being debugged. Whenever I force gdb to start from directory where the library binary file is placed (in Qt Creator it is done through additional debugger startup commands in Tools->Options->Debugger->Additional Startup Commands: just make "cd" to the directory with binary file) everything works fine.
One more solution is to set the environment variable LD_LIBRARY_PATH to contain full path to the directory with binary. In Qt Creator it is done in Project->Run Settings->Run Environment.
In order to check that debugging symbols have been loaded properly open gdb log via Window->Views->Debugger Log and type the command "info shared".
This worked for me under Linux, and I'm not sure if it'll work under Windows but here it goes anyway:
in the .pro file, I added the line:
CONFIG += debug
This enabled debugging within the QT system. Then i added the following:
QMAKE_CXXFLAGS += -O0 -g -ggdb
The -ggdb is for the gdb support. And the O (letter O) 0 (number zero) to be no optimisation - to prevent the compiler from optimising out variables. This gives me the backtraces i need with all the symbols when debugging under Linux. This is a fairly standard debugging compiling option across the board with gdb. But it may already be covered by the debug option in CONFIG.
Under Linux i rebuilt the project too:
make clean
make
But for Windows, if you're using Visual Studio, you might need to do a rebuild. I don't know what your compilation toolchain is.
I know you're using Windows, and it might be worth trying these things in case it works under Windows too. However, even if it doesn't work under Windows, it could be useful for someone searching for how to do this under Linux, so I think this is a valid answer, even though it may not specifically answer this particular question.