This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: -stack-list-locals and children
On Monday 29 June 2009 11:39:27 Vladimir Prus wrote:
> > One point was always to reduce the number of roundtrips before
> > being able to display the variable view. I think that's a valid point
> > also from a KDevelop angle of view.
>
> Right, but how variable type is helping? Is it used *just* to populate
> the "type" field in variable view? Or is it also involved in QtCreator's
> pretty-printing mechanisms somehow?
Right. They are also primary information for the current incarnation of
Qt Creator's pretty-printing.
However I don't want center the argumentation around the needs of
a specific IDE though if there is a "cross-IDE" reason. And reducing
roundtrip count should be fairly cross-IDE ;-}
> >> One important question is whether knowing a type of expression, without
> >> knowing its address, is gonna help you very much.
> >
> > Yes, as the address is not as prominently displayed in the view as the
> > type having the type quickly even without an address would help.
>
> But will address help if the object being displayed needs pretty-printing?
> Say, QString? I am not actually sure how you do pretty printing, but I'd imagine
> that address should always be needed.
I get the address filled in "for free" by gdb when invoking the pretty printers.
It's conceptionally[1] something like running "call dumpQString(&astring)"
through gdb when there is a local "QString astring;" in the code.
So I don't have a specific interest in having the address available in the
first round.However, in general I would not mind if information that's easily
available on the gdb side and that takes only a few characters would be
output. So if you added an address field I'd certainly not complain ;-)
Andre'
[1] In practice it's way more messy as this needs to work with several
versions of gdb (and other debuggers for that matter)