On Sun, Jun 2, 2013 at 6:01 AM, André Pönitz < [email protected]> 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
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
