kdevelop2.0 dbg changes

Simon Hausmann hausmann at kde.org
Mon Jun 25 21:56:41 UTC 2001


On Mon, Jun 25, 2001 at 10:59:38PM +0200, Ralf Nolden wrote:
> Simon Hausmann wrote:
> > 
> > On Mon, Jun 25, 2001 at 03:58:14PM +0200, Harald Fernengel wrote:
> > > Hi,
> > >
> > > > latin1() doesn't always work in gdb :(( hence that nasty convoluted gdb
> > > > statement you've replace. Wanna fix.... :-)
> > > >
> > > > you can test this by debugging kdevelop 2.0 and breaking on main.cpp:143
> > > >
> > > > It could be done better than I've done it, I'm sure, but...
> > > >
> > >
> > > Sorry, I am not very good with gdb (as you may have already noticed ;))
> > >
> > > The problem in Qt3 is that there is no more "rw" member in QChar, because the
> > > row and the col of a Unicode char are now stored in an unsigned short named
> > > "ucs".
> > >
> > > QChar::latin1() simply does this:
> > >
> > > { return ucs > 0xff ? 0 : (char) ucs; }
> > >
> > > since we cannot call this member function, we have to find a way how to
> > > distinguish a Qt2 String from a Qt3 string and then write a small GDB script
> > > as Simon suggested to debug Qt3 strings properly.
> > >
> > > Any suggestions welcome.
> > 
> > And then it hit me :-) . I don't know the details of the gdb frontend, but
> > kdevelop certainly knows if the application uses qt2 or qt3, right? So what
> > kdevelop could do is to feed either a qt2 implementation of printqstring
> > or a qt3 one to gdb in the initializing phase. The actual code in the gdb
> > frontend then just pipes 'printqstring blah' to gdb.
> Well, in fact it doesn't. The users will update their admin dir and
> continue as usual, so that's not the point. I also think that the
> current Qt apps do just fine with Qt 3 (didn't test it yet, didn't get
> qt from rsync to compile yet), and the configure check should also work
> although Werner Modenbach said on kdevelop that he has problems with it.
> Harald, did you run some tests with a Qt 2 app using the current CVS and
> Qt 3 ? I mean, does the configure check work and Makefiles get generated
> plus does the app still compile and run ?

The current configure checks work just fine using the qt3 snapshots.
 
> On the current problem, the obvious solution isn't a solution in this
> case unfortunately, however it would be working around the problem
> anyway instead of solving it.

there's a third possibility which just comes to my mind:

A QChar is nothing else than a simple plain ushort (binary wise) . So it
should be absolutely safe to cast it to an ushort (or char) and print it
like that. Should work with any Qt version :)
(I didn't try it with gdb though - anyone? :)

Bye,
 Simon

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop-devel mailing list