I am using gdb for debugging C project source code. I compile as shown:
./configure --enable-debug CFLAGS="-g -o0"
make --debug=a
I want to debugging stop at specific file. So when I set break point by using
(gdb) break main.c:672
It says:
No source file named main.c.
Even when I pass specific function name (in main.c file) to break . it says: such function not defined.
My current directory has this main.c file. I am using Cygwin on Windows. When I set break point by using
(gdb) break main
It set break point at a main function of Cygwin file, not in my source code.
how can I fix my first problem?
just curious, how to avoid second problem, if there is same function name within Cygwin files and my source code?
When you compile your .c file, make sure you use:
gcc filename.c -g
gdb <binary name>
Search for load debugging symbols done or not?
If not:
gdb) symbol-file <path-of-symbol-file>
you can find symbol file in obj directory
If you're compiling with -g and still not able to set a breakpoint, try adding raise(SIGTRAP) in your main(), run the process in gdb, then set the breakpoint you want again after it hits the SIGTRAP.
Crucial is gcc parameter -g during compilation.
Everything else is secondary.
See breakpoints in GDB
I also encountered with similar problem earlier. I just deleted .metadata folder and imported the particular project again and that work well.
Whenever you have to use GDB, type the following in command line
gcc -g -o outputfile sourcefile.c
Now type
gdb -tui outputfile
and then enter the break command
Related
I am trying to run my library using a make file. I currently have a dynamic library called libname.so which I created by linking the object files of some of my C files. This library works correctly when I run the following lines of code in my linux shell :
gcc -L. main1.c -lname -o out
LD_LIBRARY_PATH=.
export LD_LIBRARY_PATH
But when I copy these exact lines of code in to a make file and name the make file title for this function 'names' and then run 'make names' in linux shell, I get the following error:
./out: error while loading shared libraries: libname.so: cannot open shared object file: No such file or directory
Then once again when I run the final two lines of code shown at the end of the makefile function again then run the out file, it is fixed and the program works again.
I just need to figure out how to make it work directly from the makefile.
LD_LIBRARY_PATH=.
export LD_LIBRARY_PATH
These two lines do not influence the creation of the program in any way because you type the lines after creating the program.
These lines are not used for building your program, but they influence running the program (by typing ./out).
If you compile your program using gcc directly (not using make) and open a new terminal, you also have to type these two lines (again) before you run the program.
It does not matter how you build the program (by typing gcc manually or by running make):
After opening a new terminal, you will need to type these two lines before you run the program.
However, the dynamic linker does not only use the path information from LD_LIBRARY_PATH but also from the DT_RUNPATH information in the executable.
Unlike the LD_LIBRARY_PATH variable which is set on one console (or terminal) only, the DT_RUNPATH information is stored directly in the executable file.
As described in another question on this site, you can set the DT_RUNPATH information using the -Wl,-rpath=<value> switch:
gcc -L. main1.c -lname -o out -Wl,-rpath=.
If you do this, the dynamic linker will search your library (libname.so, if I understand correctly) in the current directory.
Note:
. really means: In the current directory; it does not mean: In the same directory as the executable file!
If your program is stored in the directory ./somedir and you type somedir/out, the file ./libname.so is searched, not the file ./somedir/libname.so.
This is both the case for the -Wl,-rpath= method and for the LD_LIBRARY_PATH= mehtod.
Following this process
from an earlier question (see answer).
gdb is a huge improvement over spim, but I'd like to use the compile code feature of gdb, to inject arbitrary mips instructions at the point of execution.
I have read Compiling and injecting code in gdb. When I run run compile code <anything>, I get the error "compilation failed, unrecognized argument -m32". Then when I run set debug compile in gdb, and I try compile code <anything> again, I see that the argument -m32 is passed to mips-linux-gnu-gcc.
I tried overriding the compilation arguments using set compile-args -march=mips32r3, which adds the compilation argument, but -m32 is still passed and still gives me an error.
How do I prevent -m32 from being passed? Is there a clean workaround (short of making a dummy script that strips -m32 before compiling?)
How do I prevent -m32 from being passed?
It looks like this is the case where GDB developers thought that "GDB knows better", and didn't provide any way to override this.
Specifically, the -m32 comes from default_gcc_target_options(), which unconditionally adds -m%d with gdb_arch_ptr_bit() as the argument.
Short of building your own GDB or providing a GCC wrapper that strips -m32, I don't see any way to get rid of this argument.
Make this script, special-gcc. Make it executable, chmod 777 special-gcc. The script uses exec to have the process replaced with the gcc invocation, as opposed to spawning a child process. Arguments are $#, stored in array, filtered in loop, then passed to the gcc invocation.
#!/bin/bash
declare -a args=()
#!/bin/bash
echo -- "----------------" >> ~/gcc-wrapper-log
for arg in "$#"
do
if ! [[ "$arg" == '-m32' ]]; then
echo -- "$arg" >> ~/gcc-wrapper-log
args+=("$arg")
fi
done
exec mips-linux-gnu-gcc -static "${args[#]}"
Inside gdb, run the command set compile-gcc /path/to/special-gcc. Attempt some command compile code <anything>. Then in gcc-wrapper-log you can see all the arguments to the compilation, can selectively disable them in the script.
For me, the compilation succeeded, but because I am using the mips-linux-gnu-gcc cross compiler binary, gdb seems not to link the resulting .o file correctly. See the docs for details on the internals of the compile code feature. Somewhere in the steps "Relocating the object file" is where the process failed for me for mips-linux-gnu-gcc.
However, this is still a clean and easy way to precisely control the compilation arguments used by gdb compile code.
I use the command gcc -std=gnu99 -g -pthread dotProduct_critical_ompi.c -I. to compile my C program and then use gdb to debug it with the command gdb dotproduct.
But the source file which gdb shows in terminal named dotProduct_critical.c is not the source file I compiled ( my source file is dotProduct_critical_ompi.c ). Why? Thanks for your help.
Update
The problem was solved after I remove the output file and recompile several times. But today, after I modified my source file, the error occured once more. And the method doesn't work any more. What can I do? (My source file is still dotProduct_critical_ompi.c)
the output of command gdb -batch dotproduct -ex "info sources" is:
I set up this toolchain on my Windows machine for my Pi (raspberry-gcc4.6.3-nosysroot.exe) and then I followed the instructions here to synchronize my sysroot.
I use a library called WiringPi in my project, and I have confirmed that it is in the synchronized sysroot:
Then I attempt to compile it:
arm-linux-gnueabihf-gcc -Wall -O -c main.c
But I get the following error:
fatal error: wiringPi.h: No such file or directory
What do I have to do to make the compiler find the header file? I thought the whole point of synchronizing the sysroot was to make this kind of thing work?
You'll have to let gcc know where to look for the include files via the -I argument. In the case above, -IC:\SysGCC\Raspberry\...\usr\local. You may have to add more than one include path, depending on where the required files are scattered. You can also try to set gcc's environment variable(s).
Finding out the correct include path can be a little tedious (see above: should it be local\ or local\include\?). Maybe you can find the environment setting for all default include paths on your Pi and just copy it over to your Windows machine.
Edit: Think I got it: echo | gcc -v -E -
To create the .out executable, I have to enter:
$: make
$: myprogram.out name.ged
My program incorporates a command line argument, thus the "name.ged".
Whenever I run gdb after getting a segmentation fault (core dumped), I enter:
$: gdb a.out core
(gdb): bt
I then use the back trace command, and gdb returns:
#0 0x4a145155 in ?? ()
#1 0x08a16ce0 in ?? ()
I even tried using the up command t move up the stack, but still no luck. I can't tell which line in my program is giving me the seg fault. gdb works with my other programs that do not involve a Makefile and command arguments, so I'm wondering if my commands are incorrect.
Summarizing the comments (before anyone else does :).
Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.
In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.
CFLAGS= -g -Wall -Wextra
You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).
$ CFLAGS='-g -Wall -Wextra' make
I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.
CFLAGS='-Wall -Wextra'
Then, when you need it, put this in the makefile to make a debuggable executable:
CFLAGS+= -g