Re: [cdt-dev] Local variables bug

["Alain Magloire" <alain@xxxxxxx>]

> 
> 
> 
> I'm looking into a cdt bug that I filed (28881).  An added comment (from
> Mikhail K.) states that stack frames that contain variables with the same
> name will map to one CDI variable object.
> 
> I don't understand what the CDI* members are in CStackFrame / CVariable /
> CValue.

In brief, CDT/debug is scatter over a few plugins:

org.eclipse.cdt.debug.core
org.eclipse.cdt.debug.ui

org.eclipse.cdt.debug.mi.core
org.eclipse.cdt.debug.mi.ui

org.eclipse.cdt.launch


The idea was to make the plugin "org.eclipse.cdt.debug.core" and
"org.eclipse.cdt.debug.ui" not dependant on a particular debugger, say GDB 8-)
To do that, we have one more layer, a set of interfaces that we call
CDI (CDT Debug Interface).  So the two plugins use this interface to
retrieve/set information on the debug session.
see:
org.eclipse.debug.core.cdi
org.eclipse.debug.core.cdi.event
org.eclipse.debug.core.cdi.model


So when you create a debug session(see org.eclipse.cdt.launch), an implementation
of the CDI is created, so far the only one available is the one base on MI/GDB
in:
org.eclipse.cdt.debug.mi.core

The CDI(ICDISession) debug session is created by the launch plugin and
given to the debug plugin that will use it from now on.
So when you make any UI actions(org.eclipse.debug.ui) it falls all the way down
to gdb.

example:
org.eclipse.cdt.debug.ui:
  void handleDoubleClick() {
    // Fetch the value of the variable.
    String value = CVariable.getValue()
    showString(value);
..
  }

org.eclipse.cdt.debug.core:

  String CVariable.getValue() {
     // Assuming a CDI session was create by the launcher.
     // Get the info from the CDI layer
     return ICDIVariable.getValue();
  }

org.eclipse.cdt.debug.mi.core.cdi

   String getValue () {
     - Create a " -var-objet - * ".
     - get the value " -var-evaluate-expression var1 "
   }

> 
> 
...
> 	
> 
> 
> What do the CID variables do/represent in these classes?  Is it a pointer
> to something more concrete?  Or are these members there to allow
> decoupling of some sort?

Yes.

Just committed a patch that should make things
clearer(?? 8).  It is not commited in the cdt_1_0_1 branch, only the head

+2003-01-02 Alain Magloire
+
+       Bug when using recursive:
+       int recursive(int x) {
+               if (x > 10)
+                       recursive(++x);
+               return 0;
+       }
+       
+       The Variable Manager is caching the MI/GDB var-obj for speed.
+       It is finding the object by looking at the name and the stack/thread,
+       for recursive calls, this is wrong and the code would be full in
+       thinking the variable "x"(see above) is the same object.  To make the distinction
+       we use the depth "-stack-info-depth" that will be use also in the equality
+       to make sure we identify an object uniquely.  In the recursive() case above
+       because the depth is different, a new "x" object will be created.  The downside
+       is that on certain platform doing deep recursive/stackframe, we have noticed
+       that "-stack-info-depth" can be very long, test done for gdb/QNX with
+       a stack depth of 1000.
+
+       * src/.../mi/core/cdi/VariableManager.java (getElement):
+       Use the depth when doing equal().
+       (createElement): Save the depth of the stack part of the Element.
+