When I run build_windows_x64_vc17_Debug\bin>%gdb% blender.exe I can see this in the gdb-console:
Reading symbols from blender.exe...
(No debugging symbols found in blender.exe)
I am building Blender from source via make debug developer ninja, am I wrong expecting it to contain debugging symbols? (The resulting blender.exe has 498MB, if that can be considered a sign of anything.)
The -g flag?
On several places I read that one should add -g flag so I added it (and then -ggdb too) into environmental variables:
set CFLAGS=-g
set CXXFLAGS=-g
...and into blender\CMakeLists.txt right after project(Blender):
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g")
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -g")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")
...and also here in the same file:
set(PLATFORM_LINKFLAGS "-g")
set(PLATFORM_LINKFLAGS_DEBUG "-g")
...the log is then full of "cl : Command line warning D9002 : ignoring unknown option '-g'"
Point to the pdb?
I also tried %gdb% --symbols=blender.pdb blender.exe, no difference.
My platform is Windows 10 with VS2022 binaries/libraries.
I doubt it matters but this is my version of gdb:
GNU gdb (GDB; JetBrains IDE bundle; build 145) 10.2
...
This GDB was configured as "x86_64-w64-mingw32".
According to this reply GDB is not compatible with what the MS-compiler creates.
GDB has a different debug format than Microsoft's compiler. Indeed the PDB format is not documented. So you can't use the debug information generated by a Microsoft compiler with GDB.
Related
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.
CMake 3.9, arm-gcc 5.4.1, Linux / OSX:
I'm enabling stack smashing protection by adding -fstack-protector-strong to my compiler flags. This instructs gcc to look for specially-named symbols in the hard-coded libraries libssp.a and libssp_nonshared.a.
These libraries exist in my application as part of the build, but they do not yet exist when CMake is interrogating my compiler during the configuration phase.
This causes CMake to fail, which makes sense:
[2/2] Linking CXX executable cmTC_0f43d
FAILED: cmTC_0f43d
/path/to/arm-none-eabi-g++ -fstack-protector-strong
CMakeFiles/cmTC_0f43d.dir/testCXXCompiler.cxx.obj -o cmTC_0f43d
/path/to/arm-none-eabi/bin/ld: cannot find -lssp_nonshared
/path/to/arm-none-eabi/bin/ld: cannot find -lssp
Is there any way to:
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Provide an empty "dummy" version of libssp and libssp_nonshared during interrogation?
Skip compiler interrogation entirely? (This is a custom toolchain.)
Or any other way to work around this?
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Just add this compiler flag after the project() call, when CMake checks a compiler.
project(MyProject)
# ...
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fstack-protector-strong")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstack-protector-strong")
Instead of appending the flag to CMAKE_*_FLAGS variable, you may also add it via add_compile_options command:
project(MyProject)
# ...
add_compile_options("-fstack-protector-strong")
In my case, option 3 turned out to be easy. In my toolchain CMake file, I simply added:
set(CMAKE_C_COMPILER_WORKS ON)
set(CMAKE_CXX_COMPILER_WORKS ON)
And now CMake doesn't waste any time interrogating the features of my compiler.
This works in my specific case (embedded systems firmware), but it would be nice how to get CMake and -fstack-protector-strong to work on non-embedded programs as well.
I use Orwell Dev-C++ IDE as my working environment. As a student and indie developer, I write both C codes and C++ codes, so I added this into "Compiler Options" settings
-std=c11 -std=c++17 -Wall -Wextra -s
Dev-C++ calls gcc.exe and g++.exe depending on file extension, so I can't create separate compiler profiles for C and C++. Then whenever I compile a program, either compiler says
[Warning] command line option '-std=c11' is valid for C/ObjC but not for C++
[Warning] command line option '-std=c++17' is valid for C++ but not for C
I am completely sure that it's safe to ignore this specific warning, but I'd like to suppress it. Is there anything I can supply to gcc/g++ so it doesn't generate this warning?
In case it depends, I use MinGW GCC/G++ 6.3.0.
In my CMakeList.txt file, I have the following in order to add c++11 supports:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
This works fine under Mac with Xcode. However, I get the following warning message from Visual Studio. Any idea?
Command line warning D9002: ignoring unknown option '-std=c++0x'
Other than the compile warning, the program gets compile and run with no problem. I am using VS2013. If I remove that single "set flag" line, the warning goes away.
The -std=c++11 option is for GCC/CLang only, it is not available in Visual Studio. C++ 11 support in Visual Studio should be turned on by default. So, you should use this option for GCC-like compilers only:
if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
endif()
If you are using the latest versions of CMake you might try to use new compiler features mechanism : http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
Microsoft Visual Studio Compiler (MSVC) has it own set of compiler flags.
In short: The solution to fix the issue is to use following command instead the one you have used.
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /std:c++17")
Use target_compile_features to get CMake to add the correct compiler flag, for C++ 11, for whichever compiler you are using
target_compile_features(mylibrary PRIVATE cxx_std_11)
or
set(CMAKE_CXX_STANDARD 11)
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.