Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Variables View / Registers View architecture.

Hi Mikhail,

    My question is about not rendering f the debugger view. 

    I would like to know the root class which is issuing the command in sequence. I would like to change the sequence of the
commands as follows :

	whatis $fr68
	whatis $fr69
	whatis $fr70
	...

	-var-create - * $fr68
	-var-create - * $fr69
	-var-create - * $fr70
	....

	var-evaluate-expression var36
	var-evaluate-expression var37
	var-evaluate-expression var38
	...	

Thanks,
Bala  

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> Sent: Wednesday, June 22, 2005 11:28 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Variables View / Registers View architecture. 
> 
> Bala,
> 
> The CDT provides only the implementation of the Eclipse Debug 
> Platform API. 
> The rendering of a debugger view is done by the view itself. 
> To find out how it wprks look at the VariablesView, 
> VariablesViewer, RemoteTreeContentProvider, 
> RemoteTreeContentManager etc. classes.
> 
> Mikhail
> ----- Original Message -----
> From: "Balasubramaniyan K" <balask@xxxxxxxxxxxx>
> To: <jdt-dev@xxxxxxxxxxx>; <cdt-dev@xxxxxxxxxxx>
> Sent: Wednesday, June 22, 2005 10:40 AM
> Subject: [cdt-dev] Variables View / Registers View architecture.
> 
> 
> >
> > Hi,
> >
> >
> > Before I explain my understanding about the Architecture of 
> Variables
> > View or Registers View, let me try to explain my actual
> > problem
> >
> > I am trying to do a remote debug operation from Eclipse / 
> CDT. Though I
> > am succesful, yet there is a considerable performance delay
> > in Variables & Registers View.
> > After conducting few experiments, we have found out that performance
> > delay is due to the network latency. In other words, Eclipse
> > transmits a command & waits until GDB sends
> > a response & vice versa. Due to this, GDB at the remote end 
> is idle most
> > of the time. For every request & response, the round trip
> > time is 203 milliseconds & for 70 variables in context,
> > the variables view takes 10 seconds to come up.  The 
> solution which we
> > could think of this, we could remove the wait state of the
> > transmitter ie., Tx keeps pumping commands to the GDB so that GDB is
> > always in state of sending response. By this , we could remove
> > 203 milliseconds for each command.  This is an idea. Is 
> there any better
> > solution ?
> >
> > Now coming to my understanding,
> >
> > For every variables for a context , there are three 
> operations that are
> > being carried viz., whatis, -var-create &
> > -var-evaluate-expression. Through the Stack-list-locals 
> commands, all
> > the local variables in the context are obtained & these are
> > dumped to the RegisterDescriptor[] or VariableDescriptor[] data
> > structure as applicable. Then there is a ***Job**** that is getting
> > created which runs all the three commands on each & every 
> variable. I
> > have *starred*  at the code for a while now .Unfortunately, I
> > am  not able to find the piece that connects these 
> ***Job*** & how they
> > execute these three commands for every variable in the
> > context & who is starting these jobs.
> >
> > Any help would be greatly appreciated  ?
> >
> >
> > Warm Regards
> > Bala
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> 




Back to the top