[Qt-creator] Qt Creator 2.7 onward does not work with some gdb on Windows

[André Pönitz]

On Sun, Jun 02, 2013 at 01:26:24PM +0530, Abir Basak wrote:
> I looked at that. Fortunately there is a test case  "GNU gdb (Gentoo 7.1
> p1) 7.1" available.  Unfortunately it parses too at wrong location, but
> presemably the test case passes as both are 7.1 I have a feel that QtC is
> wrong at parsing gdb version string and Mingw w64 version strings are
> right, because that string comes from gdb build configuration.

This string is configured at build time, by whoever creates the packages.

Qt Creator cannot know in advance what kind of version strings will be
configured, as this is essentially "free text".

>     > QtC 6.4.2 uses to load python based debuggers even when it failed with
>     > UNSUPPORTED GDB VERSION message due to wrong extractGdbVersion , but QtC
>     4.7
>     > onward handleHasPython was refactored to have a call handlePythonSetup (
>     I was
>     > unable to get which commit changed that) and it no longer calls the
>     python
>     > specific loads.
>     >
>     > I am looking for extractGdbVersion to fix for gdb version as shown above
>     (Or
>     > even a user specific override option to inform the gdb has python
>     support) so
>     > that I can work with newer QtC  versions (I have a lot of C++11 code like
>     > template alias which highlights only with newer QtC versions)
> 
>     It's not just a question of Python or not Python. The version of GDB does
>     matter when it comes to decide what features to use, or whether certain
>     workarounds are needed. In some cases it's possible to check for features
>     at run time, so the exact version does not have to be known for that. But
>     there are also cases where just trying to enable some feature freezes or
>     crashes some GDB builds while it works fine on others.
> 
> 
> Yes, so QtC should parse it right (or cover as many cases as possible),

And I am certainly not opposing the idea of also recognizing that
particular case, too, so if you have a patch, feel free to contribute.

I am, however, somehow opposing the idea of personally hunting down all
currently existing and future builds of GDB with "customized" version
strings and making sure that we can parse the version number back.

Andre'