Debugging release builds on Win32

[Dirk Hohndel]

> On Sep 24, 2015, at 7:44 AM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> 
> <extended from my short suggestion on IRC yesterday>
> 
> some time ago i was working with some people finding errors on their
> software (built with MSVC), i was surprised how fast they fix issues
> in release builds (*cough* in most cases), by just knowing the
> faulting offset in the executable, with or without reproducing the bug
> locally.
> 
> the reason for that is that MSVC compiles the debug symbols in
> external files (.PDB).
> so while they give users the release build, they also have the release
> build, but with debug symbol files.
> 
> i think this is a much wiser distribution scheme debug symbol wise,
> compared to what GCC does by default.
> 
> as i said on IRC, GDB also supports it and i have tested it with MINGW
> 4.9.2. it works for me, as long as the debug files are in the same
> folder (can't get "set debug-file-directory X" to work).
> 
> https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
> 
> GDB can also perform a bunch of gymnastics to load DLL symbols, with
> add-symbol-file, but for that one needs to know at which address the
> binary will be allocated in the process space. more awkward, but it
> also works as i have tested add-symbol-file as well.
> 
> CMAKE wise, i see they support -DCMAKE_BUILD_TYPE=RelWithDebInfo but i
> haven't tested that.
> 
> of course, here we are only interested to build some libraries (e.g.
> libgit2) and the main executable with debug symbols (-g), store the
> debug symbols in separate files and strip them from the binaries
> targeting the user.
> 
> i don't see this approach working for Qt as they already have "d" and
> "non-d" files and there is probably more than just debug symbols in
> the "d" version, but everything else which is built from source
> *should* work.
> 
> so, Dirk if you implement this with scripts on your end and next to a
> release Win32 installer upload a zip with debug symbols for our main
> faulting module candidates (e.g. subsurface.exe, libgit2.dll, etc), we
> can actually debug a release build much easier.
> 
> let me know if you are interested and i can help with examples.

I'm definitely interested. Given how fragile this has been lately I'm
freaked out that I might once again break things, though.

The crashes in libgit2 especially are weird and annoying.
I might point out (cough, cough) that I begged and begged people
to actually test this and basically no one did (well, 20 logins were
created prior to the beta, and 10 of them were used exactly once 
or twice). Whatever, water under the bridge.

At this stage I'm a long way away from being comfortable releasing
what we have as 4.5. Which means we have time to play with this idea

/D