Description Sumit Sarkar 2005-03-18 18:58:36 EST

-----Original Message-----
From: Sarkar, Sumit 
Sent: Friday, March 18, 2005 10:56 AM
To: 'Alain Magloire'
Cc: David Inglis; 'Sebastien Marineau'; Sarkar, Sumit
Subject: Serious issues while debugging in Remote Development scenario - Please read
Importance: High

Hi Alain,

In the remote development, we are facing one serious problem - the debugging is
very slow. There are two aspects of this problem: 

	Updating and displaying the name and values of the following in the current
context: 
		1. variables
		2. registers 

The first item: variables
==========================
Current implementation: (We are working on CDT 2.0.2)
------------------------------------------------------
In the method "getLocalVariableDescriptors" of
org.eclipse.cdt.debug.mi.core\cdi\org\eclipse\cdt\debug\mi\core\cdi\VariableManager.java,
"createMIStackListLocals" is getting called with the "false" parameter:

			MIStackListLocals update = factory.createMIStackListLocals(false);

which is represented as a MI command: "-stack-list-locals 0".

	public MIStackListLocals(boolean printValues) {
		super("-stack-list-locals"); //$NON-NLS-1$
		if (printValues) {
			setParameters(new String[]{"1"}); //$NON-NLS-1$
		} else {
			setParameters(new String[]{"0"}); //$NON-NLS-1$
		}
	}

"-stack-list-locals 0" emits only names of all the variables in the current
context, not the values. Later in a for loop, all the variables value are
getting asked one-by-one by calling "-var-update" MI command. In current
implementation, it takes around 8-10 secs to get the values (around 70
variables) and display them in the remote development scenario, which is
unacceptable behavior.


Possible future implementation:
-------------------------------
The MI command "-stack-list-locals 1" emits "name,value" pair of all the
variables in the current context. If we pass "true" to the
"createMIStackListLocals" call, like:

	MIStackListLocals update = factory.createMIStackListLocals(true);

we get all the names and values of all the variables in the current context. It
is much faster than calling "-var-update" one by one for each variable. e.g., in
case of 70 odd variables it takes less than a sec to get the values. 

Another point: Similarly, "-stack-list-arguments" can be called with "1" as its
first argument to get the argv, argc values.


Question: 
---------
What part of the code updates the "Variables" view tree with the current values?
We could get the "name,value" pair by using this logic ("-stack-list-locals 1"),
but the "Variables" view tree is not getting updated. When we click on the
variable, it is showing the correct value, in the bottom (vertical), but tree is
showing the old value. 
On issuing this command, the CDT code comes back with an object as follows
 
     [Line 511] MIStackListLocalsInfo list = update.getMIStackListLocalsInfo();
     [Line 512]     MIArg[] arg = list.getLocals();
 
    Using the for loop as shown below , we can get the individual variable names
and individual values. 
 
     for (int i =0 ; i< arg.length; i++) {
          System.out.println("!!!!!!!!" + arg[i].getName() + ":" +
arg[i].getValue());
          eventList.add(new MIVarChangedEvent(arg[i].getName()));
     } //This for loop does not go across the network. It just takes value from
MIArg data structure.
      :
	:
	eventList.add(new MIVarChangedEvent(arg[i].getName()));




=======================================================
Second item: Registers
=======================================================
Current implementation:
----------------------

I see the "-data-list-register-names" are being called to get the all the names
of the registers. But looks like "-data-list-register-values" is not getting
called to get all the values of the registers. (Am I missing something? I put
the breakpoint in "MIDataListRegisterValues", but it didn't hit the breakpoint
when I ask for the register values) Itanium IA64 has 587 registers. In the first
loop all the register variables get created and then second loop evaluates them.
The overall sequence of commands used for each variable name is :
	var-create $fr0
	whatis $fr0
	var-evaluate-expression var9

This is taking almost 5 mins to complete in the remote development scenario,
which is unacceptable behavior.


Possible future implementation:
-------------------------------

The MI command "-data-list-register-values" can take multiple register names as
arguments. If we pass all the register names got from
"-data-list-register-names" to the "-data-list-register-values" as following:
	-data-list-register-values <fmt> <register 1> <register 2> ...

then in one call we get all the register names and their values. It will
significantly improve the performance in remote development 



As we are planning to contribute the code back to Eclipse, these issues need to
resolved before that. We need your help in this regard.

Thanks,
sumit




-----Original Message-----
From: Alain Magloire [mailto:alain@qnx.com] 
Sent: Friday, March 18, 2005 11:34 AM
To: Sarkar, Sumit
Cc: Alain Magloire; David Inglis; Sebastien Marineau; mikhailk@qnx.com
Subject: Re: Serious issues while debugging in Remote Development scenario -
Please read


How about a conference call next week, pick the date.
I would like Mikhailk  to participate, but is not here today.

Basically there are a few reasons why things are done this way.
- Book Keeping:
   The variables are not probe.
- and the Use of gdb varobj to manage the variables.
   We need the type of the variable, doing -stack-list-frames
   does not show the types.

Maybe we can look at ways to improve this and answer any other questions.

--
alain

-----Original Message-----
From: Sebastien Marineau [mailto:sebastien@qnx.com] 
Sent: Friday, March 18, 2005 11:36 AM
To: Alain Magloire; Sarkar, Sumit
Cc: David Inglis; Mikhail Khodjaiants; Derrick Keefe
Subject: RE: Serious issues while debugging in Remote Development scenario -
Please read

Folks -- we should also make sure we do this communication on the mailing list
and not through email, to ensure it is all transparent (and if there is a conf
call, that others have the chance to listen in).

Thanks,

Sebastien