[Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK

[André Pönitz]

On Fri, Apr 20, 2012 at 11:19:50AM +0200, Pau Garcia i Quiles wrote:
> On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown
> <andy.fillebrown at gmail.com> wrote:
> > On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz
> > <andre.poenitz at mathematik.tu-chemnitz.de> wrote:
> >> On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote:
> >>> I would add to the "proper compiler" list the ability to set debug
> >>> breakpoints quickly and proper display of call stacks across .dll
> >>> boundaries.  IMO those are the two things that bug me the most about
> >>> the "distros" already mentioned.  Waiting 2+ minutes for the debugger
> >>> to start, and then not being able to see a complete callstack, is
> >>> frustrating.  So much so that I find myself going back to Qt's GCC 4.4
> >>> release.
> >>
> >> Does that mean you have experience with both the 4.4 version
> >> that's currently distributed, and the version from
> >> http://sourceforge.net/projects/mingwbuilds/files/
> >> and you found the latter lacking?
> >>
> >> Startup time should be mostly related to gdb, less so to the
> >> debug information gcc creates...
> >
> > Yes, I have experience with many versions and I have always reverted
> > back to qt's gcc 4.4 release due to the issues with gdb.  I'm trying
> > out the gcc 4.7.0 version from
> > http://sourceforge.net/projects/mingwbuilds/files right now.  I'll let
> > you know if I find it lacking, too.
> >
> > I realize there is a distinction between gcc and gdb, but since gdb is
> > included in the distro I thought I'd bring up the issues I've had,
> > seeing that the gdb from the distro might be the gdb included in the
> > Qt SDK.
> 
> Have you tried this?
> 
> http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3699

That patch is in gdb proper since November. The behaviour is
now user-selectable using 'set basenames-may-differ on/off'.
I did not see much of a difference when I tried it, though.
(On Linux, might be different on Windows)

What _does_ make a difference (like saving 30% of the time) is
a properly setup .gdb_index section in the libraries. The main
problem here is that this is a moving target. gdb keeps changing
the format of the section, and if they do not match you don't
get the performance boost (and until very recently gdb was rather
silent about mismatches.)

So when you see a massive degradation in startup times, one
explanation might be that you had initially working .gdb_index
setup, but the upgraded gdb does not like the format anymore
and silently falls back to the slow path.

Andre'