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.
Related
One of my users is getting an error message when trying to compile a C part of our mixed C/C++ codebase on ubuntu 12.04 with gcc 4.8.1
We have a library in C++ with some C-linkage functions in, and want to compile a C program linking to it. The library is compiled with g++ and builds fine. The c program fails like this:
> gcc -O3 -g -fPIC -I/media/Repo/lcdm/code/cosmosis/ -Wall -Wextra -pedantic -Werror -std=c99 -o c_datablock_t c_datablock_test.c -L . -lcosmosis
cc1plus: error: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [-Werror]
The program has a lower case .c file suffix, so why does gcc try to compile it as c++ ? We have not seen this on other OSes.
(I know we could kick the problem down the road by removing -Werror or handle this particular file with -x c but I'd like to solve the real problem.)
why does gcc try to compile it as c++
I can think of only two plausible explanations, and they both are end-user's fault.
It could be that the user transferred sources via Windows, and the file is really called C_DATABLOCK_TEST.C, and the user is misleading you.
It could also be that the user overwrote his gcc with g++ (surprisingly many people believe that gcc and g++ are the same thing, but they are not).
To disprove the first possibility, ask the user to execute his build commands under script, and send you resulting typescript.
To disprove the second, ask the user to add -v to the compile command.
This look like GCC Bug 54641, which has been fixed in a later release of GCC. It is only a warning, but your compile flags are causing GCC to treat all warnings as errors.
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'm trying to build google-glog on Mac OS X 10.8, using following options:
./configure CXX='clang++' CXXFLAGS='-std=c++11 -stdlib=libc++'
Despite that the library gets linked with libstdc++.
Why, and how to fix this?
It's better to put 'dialect' and runtime flags in the compiler variable, since it will use those flags for linking - not just source compilation: CXX="clang++ -std=c++11 -stdlib=libc++"
Save CXXFLAGS for things like -W -Wall -O2 -march=xxx, etc.
Found out that you could use the build variable
LIBS+="-stdlib=libc++"
Seems to me a better place than the compiler variables.
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.
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.