I can successfully build the same C++ code using GCC-8 for Debug (-g -O0) and Release (-g -O2) build.
I can successfully debug the Release-executable on a remote host, but I can't debug the Debug-executable on a remote host, because the Debug-executable imports an extra symbol _ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv from release version of libstdc++ which doesn't exist.
but I don't want to debug libstdc++, so I think I shouldn't install additional debug version of libstdc++.
it looks like a bug, or am I wrong?
Related
I'm trying to debug a segfault in some code built with mingw-w64's version of gcc. Since no Windows build of gcc includes the Address Sanitizer, I've been looking for a version prior to 4.9 that would allow me to use Mudflap instead.
(It has to be 4.8 or earlier, since Mudflap was removed from gcc in 4.9 - see https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging)
I've tried using downloads of 4.8.1 and 4.6.4 from https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/ - but my builds all fail with cc1plus.exe: fatal error: mf-runtime.h: No such file or directory.
I have tried using the original MinGW as well, but 4.5 as downloaded from
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.5.0-1/
just fails silently with error code 1.
Is there any site that still hosts a mingw-w64 build of gcc old enough to include mudflap? Preferably with SEH threads instead of SJLJ. If not, is there anywhere I can download a mingw-w64-compatible set of libraries and headers to install mudflap to work with an existing build?
Using Visual GDB in Visual Studio to debug an existing APK with same codebase but it reports that no debugging symbols are being found in native libs and thus no breakpoints being hit. Would have thought that are included with -g in clang options and in debug packaging config with ANT. Unless they are stripped out in signing.
I use the MSYS2 mingw-w64-x86_64-toolchain group to build my code and stack traces would be more useful if I had debug symbols for the standard library libgcc.
I have searched on the package manager and Google, but can't work out how to get debugging symbols for the standard library. I would expect a mingw-w64-x86_64-gcc-devel or mingw-w64-x86_64-gcc-dbgsym package.
Would I have to compile gcc from source?
Yes you need build GCC yourself with debug enabled. MSYS2 provide only release builds
I'm using the Ubuntu packages to develop against the LLVM libraries. Here are the packages I have installed:
libllvm3.1
llvm-3.1
llvm-3.1-dev
llvm-3.1-runtime
llvm-3.1-source
'llvm-3.1-source' contains the source code, but as far as I can tell, none of them contain the debug symbols. So when I get a segfault deep inside some LLVM code, I can't tell at what line of source code it occurs.
How do I get the debug symbols?
LLVM is quick-and-easy to build from source. Download the source packages from http://llvm.org/releases/download.html#3.2 and follow the instructions to build in debug mode. Then you can have full debugging capability into LLVM itself.
I need to find why fftw is segfaulting, in an application which built OK on 32-bit target with gcc4.0 and now fails on a 64-bit target with gcc4.6.
The fftw configure options:
--enable-debug
--enable-debug-malloc
--enable-debug-alignment
only appear to add internal debug, I was hoping to get somewhere by turning on gdb debug symbols so I can try to trace the cause of the segfault. Is there an option for gdb debug that I've missed somehow?
Alternatively, is there any other way I should be trying to track down a segfault in fftw?
As noted in my comments above, the answer was to edit the Makefile produced by fftw3's configure to add -ggdb to the CFLAGS.