Re: [cdt-debug-dev] Really Fixing Arrays

["Alain Magloire" <alain@xxxxxxx>]

> 
> 
> >It is on my todo for the head.
> 
> Great! I look forward not to our not having to make the same changes when 
> we update!
> 
> When you are considering this on the head, there is an area where you can 
> further affect user perception of speed. The array fetching with [] syntax 
> is fast enough so that while range may be "better", the end user experience 
> is not going to change much.
> 

I dare not put a time on it, since I'm off/on during the summer.
But It will be in the September 1.2, the problem is so severe
that is worth to shuffle the priorities and get this in.

> However, stepping through frames with big arrays is still slowed -- even 
> when those arrays are not opened. (hence no new -var-creates have been issued!)
> 
> The problem is that GDB slows once you do a -var-create on a 16k array. You 
> don't even have to get the children for every GDB interaction to slow down! 
> The variable being there causes the problem. The next user perceivable 
> problem to fix here is getting the total array size without having to do 
> that var create on the top level array.
> 
> It used to be that the size of the array was determined by the number of 
> returns from -var-list-children! That's one of the things that we had to 
> fix since fetching everything to determine the number of bins is clearly 
> unacceptable. Now that information comes from the string that comes back 
> from -var-eval-expr on the 16k variable. The remaining  problem is that 
> creating that variable slows GDB on all subsequent operations. It's 
> livable, but annoying.
> 
> If anyone has any fast and easy ideas on that, I'd love to hear them.
> 

Agreed, I see where you going.

We could make this possible.  ICDIVariable and ICDIVariableObject will have
a new method:
	ICDIType ICDIVariable.getType()
	ICDIType ICDIVariableObject.getType()

Where types are:
ICDIType
	- ICDIArrayType
	- ICDIPointerType
	- ICDICharType
	- ICDIIntType
	- ICDILongType
	- ....

So when you have a variable object(ICDIVariable) you can ask for its type.
On the ICDIArrayType class we could add a new method to fetch the
array length, this will not require the creation of GDB var-objects.

This could be implemented with gdb "ptype" and "whatis"
so:

char buffer[32];
(gdb) whatis buffer
...
(gdb) ptype buffer

clever parsing would give the lengths and the type.



Note:

This is part of the "variable bookeeping" we've put
for CDT/Debug 1.2 roadmap.

In brief the Variable view can be customize to not create
the GDB -var-objects. It will list all the variables return from doing
-stack-list-locals

It will be up to the user to enable which variables are
actually being created.

The rationale is for embedded dev.  For example,

volatile int my_variable;

"my_variable" actually could be some special variable
that is updated via registers are some map memory etc ..
Accessing the variable "my_variable" is very intrusive when debugging
an embedded target. The CDT/Debug is very proactive/intrusive in probing
the variable values at every step and by doing this bring dow the
target.  This scheme will let the user choose the variables that
will be updated/probe.

For the future if the CDT Parser is bright enough we could see the
qualifier "volatile" or some other special qualifier and disable
by default the probing.  Or some IMarker on the IFile(ITranslationUnit)
the the ICElement (after the CDT AST parsing).

8-) I can see JohnC(the parser guru) going HAAAAAAAAAAA!!!