I have a program that I intend to distribute to end users, and would like to have receive crash reports from them. If I were using MSVC, I would generate minidumps and have those sent to me, and then inspect them with the corresponding PDB to get a useful stack trace, at the very least.
What is the equivalent of doing this with GCC? I can generate a stack trace, but if I want this to be useful, it requires having debug symbols compiled into the executable (with -g). Obviously this is unacceptable for release distribution, since the executable can balloon in size quite a bit.
I googled a bit and found references to objcopy being able to separate out debug symbols to a separate file, but that page implied I would still need to have the debug symbols available alongside the release executable, which again is obviously unacceptable.
Well the idea is that you compile with -g to add debug symbols but not slow the program down, ie. most programs will do -g -O2 then you can seperate debug symbols with objdump. After that you can strip your release build so it won't have any debug symbols.
Update: Recent gdb supports separate debug files, see https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
For example you can doo
objcopy --only-keep-debug prog prog.debug
strip prog
Now your prog won't have any debug symbols. But you can use proc.debug file to debug it in gdb.
I couldn't find an exact answer to this, but I found an alternate solution that works just as well: Compile with optimization and other release flags alongside -g, store the resulting executable somewhere, then remove debug symbols using strip. Ship the stripped executable, and when you get a stack trace, use addr2line in combination with the original, unstripped executable, and you should get all the symbols back.
Related
when you inspect mingw you will find the c compiler cc1.exe (funny growing in size in 9.2 it is almost 25 MB ) cc1plus.exe is c++ compiler (same sizes) collect2.exe is linker (afiak) nut what is lto1.exe?
i googled for it more than hour but not found info on this.. is there some good info on this avaliable to read? tnx
ps. i suspect that it may be related to link time optimisation but found nothing more about it and i would like to know better
there is also a question what is gcc.exe g++.exe and mingw32-gcc.exe mingw32-g++.exe then
i need more informatin, the most the better , tnx
This is not mingw / Windos specific; it's a feature / component of GCC.
what is lto1.exe?
It's the lto compiler :o). lto is basically byte code written when compiled with -flto where "lto" or "LTO" stands for "link-time optimization".
These optimizations are not performed by the linker but by the compiler at link time to perform global optimizations when (byte-)code from all the modules is available. The flow is as follows:
The C/C++ compiler (cc1 for C or cc1plus for C++) compiles C/C++ to byte-code and writes it to the assembly file *.s.
Assembly is assembled by the assembler to object code *.o as usual. lto-code is shipped in dedicated sections.
At link time, the linker (plugin) calls back the compiler and supplies all the objects and libraries as requested. byte-code is extracted, and the lto1 compiler compiles it to final machine code.
The final machine code is assembled by the assembler to object code.
The linker links / locates these objects to final executable code.
You see the byte-code in the lto sections with -save-temps and having a look at the saved *.s files. Recent versions of GCC don't even bother with writing assembly code; they are just writing lto code. To see the assembly code, specify -ffat-lto-objects. Notice however that this is not the final code.
funny growing in size in 9.2 it is almost 25 MB
The sizes of GCC executables depend not only on the GCC major version, but also highly on how well the compiler used to build GCC is optimizing.
[Edit] Some information on LTO can be found on the GCC wiki for LTO. Notice however that this page is no more active. One goto place for gory GCC internals is the gcc-help#gcc.gnu.org mailing list where all the developers are. There is also a section about LTO in the GCC internals.
LLVM debugger (lldb) uses a source file for debugging (e.g. for breakpoint). I want to use lldb without having source files, only with intermediate representation files (.ll files).
Is it possible? If not, can I do that with gdb debugger? Is there another idea?
I'm not sure you can debug using the IR, but in the worst case, you can always just debug the bare assembly without symbols of any kind. Having at least function labels is nice, though.
With g++ with -g option, I can use gdb for debugging purposes.
What's the equivalent to this option with Visual Studio 2010 cl.exe compiler?
This page has different libraries (debug/release) for linking.
If I compile with debugging option with cl.exe, do I have to use the corresponding library linking options (/MD/MT vs /MDd/MTd)?
There are a few separate pieces to this question: how to tell the compiler/linker to generate and preserve "debug information" (mapping between source code and object code), how to tell the compiler to compile the code differently to make debugging easier (think of assert() and #ifdef _DEBUG), and whether the precompiled libraries you link into your project include debugging information.
-Zi (flag to the CL compiler to tell it to generate debug information) is the equivalent of gcc's -g flag.
(There are other forms of the -Z option: -ZI if you want the "edit and continue" support in the Visual Studio IDE, but if you're using the IDE you're probably using its interface to the compiler settings instead of manipulating them directly, and -Z7 if you want the old CodeView-format debug information; whenever I've invoked CL directly it's always been -Zi that I wanted.)
Note that using the -Zi (or -ZI) option will generate a .pdb file per directory, usually, but when you link code together, it may have come from .obj files represented in different .pdb files, and you also want to combine those separate .pdb files into a master one representing the code you linked together -- this is what the -debug switch for the linker is for.
Also note: this may sound counterintuitive, but always use -Zi (for CL) and -debug (for link.exe). Even for code you're going to release. It doesn't increase the size of your executable, or give away secrets to your customers, since the debug information goes in a separate .pdb file (which you won't ship to customers). If there's any chance you're ever going to have to debug it, you're going to want the .pdb. (-Zi isn't even incompatible with optimizations, though -ZI is. So you might want to compile your "debug" builds with -ZI, and your "release" builds with "-Zi -O2".)
As for the libraries: you don't strictly need to match the debug/release property of the C runtime library with whether your code includes debugging information, but it's usually a good idea -- if you're going to debug the project you want to be able to debug all of it, and if you're not going to debug it you don't need the extra weight. Using debug/release versions of a given library won't affect whether it has debug symbols available (hopefully, if whoever compiled the library understood the point I made in the previous paragraph), but it will affect things like assert and extra #ifdef _DEBUG code in that library.
This goes for all libraries you link with, but especially for the C runtime library -- Microsoft added extra error-detection code to malloc() and free(). So if anything in your project is using the debug flavor of the CRT library, all of it should be.
The /M options (/MTd and /MDd) are weird and magic, in my opinion -- they're just aliases for a complicated set of other stuff going on behind the scenes. Take /MDd for example, documented to "Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file." Here, it's affecting both the preprocessor (defining _DEBUG and some other preprocessor symbols) and the linker (it actually puts a #pragma comment(linker) in your source code). If you care about what's going on and don't understand it, this can cause real problems -- I've seen a lot of projects that don't use the IDE get bogged down in warnings about both msvcrt.lib and msvcrtd.lib being linked in, etc. By the time you understand how to use these (/M options) safely, you don't really need them any more! I prefer to make things explicit: specify "-D _DEBUG" directly where I need it, specify which libraries to link with explicitly (and use -nodefaultlib), and then the /M options aren't needed.
You're looking for one of the debug information generation options (/Z7, /Zi or /ZI).
If you use one of those, you should also pass the /DEBUG option to the linker.
You will also need to link against the debug version of the runtime libraries (/MDd or /MTd). This is important because these versions are different from their release counterparts (e.g. their memory allocations routines are not compatible).
I wrote an LLVM transformation that basically replaces mallocs by kind of guarded mallocs and some other stuff.
I'm using clang (or llvm-gcc) for compiling a c file to get a bitcode file (using the -emit-llvm option) which contains debug information. These also contain method names, line numbers and so on.
Afterwards I'm using opt to instrument this bitcode file. The result is an instrumented bitcode file, still containing all relevant debug infos.
In a third and last step, since we need some runtime libs, we link the bitcode against some other bitcode files using llvm-gcc to get a final binary.
This binary I cannot debug since it doesn't contain any debug information although all linked bitcode files did contain them. The only thing gdb can tell me is in which function we are but no line numbers and so on...
I would be grateful for any hints.
As I understood you are running optimizations (opt tool optimizes the code and debug information also). So may be the missing part which you want to see when debugging is a result of optimized debug information ?
P.S.
I would add this in the comment, but unfortunately I don't have 50 reputations which are needed to add a comment.
I'm trying to analyze a mini crash dump and need symbol files in order to get more details about the crash. Im currently just seeing:
"034eff74 0086eee9 00000000 0089d58d 034eff94 app_integrator!ZNK14ACE_Data_Block4baseEv+0x6"
Is it possible to extract debugging information from a msys/mingw gcc built dll into a windbg readable format? If not, is there any other way of getting more detailed information, like loading a MAP file in some way?
The dll and all it's contained .o files are built with the -g flag.
Windbg can't cope with the debugging information that will be generated by -g on a mingw installation. However, it can allegedly cope with COFF symbols.
If the source files for your DLL are small enough, you can probably get COFF debug information to build (-gcoff rather than -g).
So, Windbg can (allegedly) handle COFF symbols and GCC can generate them. So it should be easy from there, right? I was trying to do exactly this with a Win32 executable generated by Visual Studio 2008 that was loading a gcc-compiled DLL. Unfortunately for me, compiling with -gcoff didn't work. Mingw's gcc won't generate COFF symbols for projects with more than 64k lines of code. The DLL I was using was distincly larger then 64K code lines. Sadly I have to admit, I gave up and fell back on the trusty OutputDebugString. Otherwise I'd be able to give more complete instructions. I didn't fancy investigating the option of making gcc do COFF symbols for larger source files, or the alternative option of writing a debugging extension to parse DWARF or STABS data into windbg's internal symbol tables.
I fixed the issue, by the way!
Further suggestions can be found in this forum post at windbg.info.