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

Abir Basak abirbasak at gmail.com
Sun Jun 2 09:56:24 CEST 2013


On Sun, Jun 2, 2013 at 6:01 AM, André Pönitz <
andre.poenitz at mathematik.tu-chemnitz.de> wrote:

> On Sat, Jun 01, 2013 at 05:04:07PM +0530, Abir Basak wrote:
> > I noticed that my MinGW w64 gdb stopped working when I updated from QtC
> > 2.6.2 to QtC 2.7 . It no longer loads stack frame and locals and
> > expressions automatically. The gdb is from MingW w64 project build by
> > ruben vb , And it shows like GNU gdb (rubenvb-4.7.2-release)
> > 7.5.50.20120920-cvs
> >
> > I previously mailed about it, but there was no update after an initial
> > reply. I looked at the source code of QtC to check if I can detect why it
> > is not working (unfortunately I can not build & debug QtC, as I do not
> > have a Qt distribution, I use it for my C++ library with make file based
> > project).
> >
> > It looks like extractGdbVersion does not handle the gdb version like the
> > one shown above. From code it looks that it parses 4.7.2 as gdb version
> > and makes it 407020, while it should go for the last part. I do not know
> > standard gdb versioning strategy but it looks many use vendor specific
> > information in brackets, so it should reject any number inside brackets.
>
> If that's indeed the reason (and it sounds plausible) someone should
> maybe ask the person providing that GDB build to not patch the version
> string, or at least to not deviate too much from what other distributions
> do.
>
> A couple of version strings that are recognized are in the
> "version" test in test/auto/debugger/tst_gdb.cpp.
>
> 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.

> > 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),
specifically when Qt itself in Windows uses Mingw w64 (Though i heard it
uses mingw builds by nixman rather than build by ruben)
Moreover python feature can be detected without version information.
However , as I said, my diagnosis about the problem is just by looking at
the source, and I had not build QtC , so I may be totally wrong.
As a user of QtC I wish the Mingw w64 build by ruben vb should be
supported, as it was upto QtC 4.6.2

> Andre'
>
>


-- 
Abir Basak
B. Tech , IIT KGP
Research Engineer & Technology Lead,
Read Ink Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20130602/8e1b94c9/attachment.html>


More information about the Qt-creator mailing list