This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Python/MI/STL visualization


On Wednesday 23 April 2008 09:46:07 Vladimir Prus wrote:
> >> 1. Vectors can get large, and getting them can get slow. Do we want to have
> >> incremental fetch of some kind? On UI level, I'm thinking of something
> >> like KDevelop's incremental fetch of frames, see
> >> http://vladimir_prus.blogspot.com/2007/02/debugger-stories-stack-widget.html
> >> But we also need MI level support.
> > 
> > Specifying a 'child range' might do the trick. Maybe
> > 
> >   -var-set-child-range V <from> <to>
> >   -var-set-child-range V *      /* reset */
> > 
> > or such, and  whenever data is reported, only children in the range
> >  <from>...<to> are reported.
> 
> Or adding range parameter to -var-list-children. In either case, I'm not yet sure 
> how to make Python interface support this. Of course, we can always make python
> side use iterators, which will work for the case where we fetch more children at
> the end.

Or that ;-)

>  [...]
> >> 4. We still have the problem that GCC debug information will say that variable
> >> exists even before the constructor for that variable has run. So, creating
> >> robust visualizer is rather hard. Anybody knows if we can workaround this?
> > 
> > Well, I run "visualizer code" injected into the inferior and trigger it with
> > gdb's "call". I do not even try to make them robust after noticing that
> > there is not enough information available. But simply letting them crash
> > and handling the segfault works rather nicely as far as I can tell ;-)
> 
> Well, segfaul is not scary. What is scary is if due to uninitialized data,
> the amount of the children the visualizer wants to fetch end up been 10000 :-)

Indeed.

My "solution" here is to wildly poke around in the structure hoping to 
trigger a segfault early and interpret such segfault as "uninitialized object".

So if there's a std::vector<> with size() reporting a non-0 value, try
to access the first and last element and one from the middle and 
hope that at least one of these addresses are "bad" ;-)

In practice, this works rather nicely. The bigger the reported size()
gets the more potential harm would actually listing the children do,
but the more likely it also is to recognize the object as uninitialized.

Of course, not having to play such "games" would be much nicer ;-}

Andre'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]