I wrote an OpenCV program, compiled by gcc -g *.o -o *, run successfully. However, when i try to use gdb debug this program, like gdb cvmat, it doesn't work. How can i use gdb debug an opencv program?
While your program is compiled with debugging symbols (using the -g flag), it sounds like OpenCV was not. Try rebuilding your OpenCV installation with debugging symbols by setting CMAKE_BUILD_TYPE to Debug or RelWithDebInfo when configuring your build with ccmake.
I had no luck with -D CMAKE_BUILD_TYPE=Debug. I could use the resulting library, but I wasn't able to debug inside OpenCV functions. Using cmake-gui didn't fix things for me either.
I was able to debug inside OpenCV by manually compiling the library components that I was interested in...
g++ -g -I ../../include/opencv/ -I ../../3rdparty/include/ cxlapack.cpp cxmatrix.cpp ../../lib/libcxcore.so my_source_file.cpp
Combination cmake -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo -D CMAKE_BUILD_TYPE=DEBUG successfully appends debug information.
Related
I have installed gcc-plugin in my Ubuntu 16.10-32 bit and the installation have been done correctly:
>$ gcc -print-file-name=plugin
/usr/lib/gcc/i686-linux-gnu/6/plugin
However, when I try to compile the plugin, I get a huge amount of errors, warning, and exceptions ...
I can not understand what is the reason behind this.
Is it a mistake in the compiling command line? or the installation of the gcc-plugin was not the right way?
I have compiled the gcc-plugin file as follow:
gcc -g -I`gcc -print-file-name=plugin`/include -fpic -shared -o my_plugin.so my_plugin.c
any help?
You have to use the C++ compiler g++. The command line looks otherwise ok, but I don't know your source code, of course.
I'm not able to see source code in lldb, despite trying to the advice of LLDB not showing source code
I've boiled this down to a simple C++17 program that is compiled with the following command. I'm running on OSX with clang 7.0.1 that I've compiled myself from source, but my lldb is the XCode-installed one (this may be a problem?).
Here's my compile command:
clang++ -std=c++17 -march=native -Wall -g -O0 main.cpp -o main
Note that main/main.dSYM/Contents/Resources/DWARF is created when I compile and that seems fine.
One clear issue, though, is that debug info is not in the binary and the object file can't be found at all:
$ dsymutil main
warning: (x86_64) /var/folders/c1/vxvr6h9x10b8dbsxhh6nx05h0000gn/T/main-43ca25.o unable to open object file: No such file or directory
warning: no debug symbols in executable (-arch x86_64)
I was under the impression that I can just compile with debug info (via -g) and have everything "just work" but that's clearly not the case.
How can I get debug symbols to work so I can use lldb?
I was able to solve this problem by removing the -flto linker flag that I didn't realize I had on. Apparently, when LTO is enabled, debugging symbols do not work.
I have built clang 3.6 from source and followed the rather straightforward instruction on the page and installed ninja, which I confirmed can build clang-format.
My question is quite simply how to pass some flags so I can get debug symbols because I do not want to do my work (modifying clang-format) using disassembly throughout.
This can be through the standard build (which uses CMake) or ninja.
I've faced similar issue recently (I wanted to debug clang's code itself). Turned out that you need to explicitly specify -DCMAKE_BUILD_TYPE=Debug when you run CMake to generate Ninja or standard makefiles.
BTW, be careful: with this Debug option ld "ate" about 4G of my RAM to link clang binary...
I have a file called val_ref.c and I compiled it using the command flag:
gcc val_ref.c -DDEBUG
after that, I opened gdb using the following command:
gdb a % the resulting execuatable is called a
Then I used the following commands to set breakpoints and run the debugger:
(gdb) break main
(gdb) break incvar
(gdb) run
(gdb) continue
However, I cannot see the line-by-line proceeding information on the console. Instead, I see this:
I am not sure what I am doing wrong. For example, if I was to build this as a console application in VS2010 or Eclipse Kepler (with MinGW toolchain), and then run gdb on the exec, it will work perfect, (I think). Seems like I am not adding the correct directives/flags in my compile. Can anybody help me with it?
How about the -g flag? This the usual flag for gdb..
The best flags to use to compile for debugging are -g and -O0. -g causes GCC to add debugging information to the executable, and -O0 stops GCC enabling optimizations which would be confusing when debugging.
I have a simple c++ program I am trying to debug, but gdb cannot find the object file for the libraries (or no debug info is available), and it does not seem able to find the debug symbols for my executable either.
I am on OSX 10.5.8, with macports, and I compile my code with
g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -I/opt/local/include -L/opt/local/lib -lgsl
-static-libstdc++ MCMC-simplex.cpp -o mcmc
(there is only one file, and g++-mp-4.5 is the macports executable for gcc/g++ 4.5 )
When I try running gdb on the resulting executable, I get many error messages (at startup) of the form
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/trunctfdf2_s.o" - no debug information available for "../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c".
which to me indicates that macports has a bug during its build (it seems like gdb is looking for the object files in the temporary build directory).
I should add that when I try to see my programs listing in gdb (the one provided by Apple), it tries to look for a random .s file in /var/tmp, which to me sounds like an assembler file. That is why I say it does not seem able to find the debug symbols for my program either.
When I try MacPorts gdb 7.1, I get
warning: `/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o': can't open to read symbols: No such file or directory.
(no debugging symbols found)...done.
and none of the many error messages that Apple's gdb gives out (although the end result is the same).
Has anyone come across this problem, and came up with a solution?
Unlike other UNIXen, on MacOS the debug info is not linked into the executable. Instead, the executable has a list of object files which were linked into it, and the debugger looks for debug info in these individual object files.
If you remove the object files, then you can't debug.
When you compile and link the executable in "single step", GCC does this:
Create assembly file /tmp/[random-string].s
Assemble it into /tmp/[random-string].o
Link /tmp/[random-string].o with crt0.o, libc, etc. into mcmc executable.
Remove /tmp/[random-string].o and .s
It is that last step which prevents you from debugging.
Solution:
g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -c MCMC-simplex.cpp
g++-mp-4.5 MCMC-simplex.o -lgsl -static-libstdc++ -o mcmc
This will leave MCMC-simplex.o in the current directory, and will allow GDB to find debug info in it.
Well, another "trick" to keep going with a single compile-and-link step would be to add
-save-temps=obj
to your g++ command line so that
4 Remove /tmp/[random-string].o and .s
is actually sort of not performed (actually you end up having the canonical SOURCE.o and SOURCE.s files in the directory where you're building instead of RANDOM-STRING.[os] in some temp folders, but from the point of view of locating debugging symbols that's fine
It seems to me you had two problems: 1) no debug symbols for executable and 2) no debug symbols for some shared libraries that generated warnings. I was also having problem 2). Employed Russian answered 1) and pointed me in the right direction for 2).
First, if you don't need to debug the libraries mentioned in the warnings, then they can be safely ignored. But of course the warnings are annoying and could hide other problems. In your case and mine, the libraries installed by MacPorts should have had debug symbols stripped, but didn't. The reason that causes a warning is, as Employed Russian says, because the symbols themselves are kept in object files generated during the build process and not in the installed libraries. The libraries store pointers to the object files as part of their (minimal) debug information.
You can verify this with the strings command. If you're gettings warnings that /crazy/path/to/something.o can't be found when loading libsomething.dylib:
strings - libsomething.dylib | grep something.o
Note that you need the '-' (this got me the first time).
To fix it, strip debugging info like so:
strip -S libsomething.dylib
Afterwards, 'dwarfdump --file-stats libsomething.dylib' should show that the "STABS debug" section is empty. (The links to object files are stored in STABS debug format.)
No more ugly warnings.. yay!
That was way too hard.