Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] FW: RE: -var-update using formatted value

Hi Marc,
It seems that the question of what and how much to cache in the IDE comes up periodically.  In the past, a rule of thumb that we used is that if a given request may go over the network, it's probably worth caching.  For GDB, i think using a remote GDB server would involve executing GDB commands over the network, although I honestly can't tell how common is that use case. 

We used this rule of thumb because the UI components using the service may be rather dumb and may request the same data over and over while painting in the UI.  That said, we are also currently implementing more caching at the UI level and improving the efficiency of UI in general, which should reduce the importance of the caching in the services.  So I think at this point the question whether to cache _expression_ commands should depends most on what is most convenient to the implementation  The _expression_ command caching is already in place and it's pretty well tested.  However from the discussion on the GDB mailing list it seems that the GDB _expression_ protocol is so convoluted that keeping a client-side cache consistent is problematic. 

>From the two caches you list below, the first cache (meta command cache) seems more important to me.  I doubt whether the second cache has that much performance impact since it's relevant only after each resume command.


Marc Khouzam wrote:

I think point 1 in the below email is good one.

I had started blurring the concept of backend and GDB, but in our DSF setup,
it is true that GDB will be running on the front-end, right?
With the GDB-Server on the backend. Therefore, whatever is cached by GDB, needs not 
be cached by our GDB/MI implementation. Is that correct?

So now, I wonder about the usefulness of two of our caches of the ExpressionService.

1- the special meta command cache may not be necessary, since GDB should already be 
caching those values.  Although this cache does work and can be a good example for
other debuggers that don't cache as GDB does.

2- the format-value cache which could simply rely on the internal GDB cache
as mentioned in the email below.  Since this cache needs a workaround to properly
work with the current implementation of var-update, it would be easier to get rid
of it.  But that means that after every 'Resume', each value, even if not changed
will need to be fetched from GDB (but not from GDB-server).

Any opinions?



-----Original Message-----
From: gdb-owner@xxxxxxxxxxxxxx [mailto:gdb-owner@xxxxxxxxxxxxxx]On
Behalf Of Vladimir Prus
Sent: Thursday, January 17, 2008 1:02 PM
To: gdb@xxxxxxxxxxxxxxxxxx
Subject: RE: -var-update using formatted value


If I have a varObject displaying 0x1 in hex and then I want to show the
value in binary, I will need to go to the target.
No. GDB keeps the raw value inside the variable object, and changing
format only changed the way gdb converts that raw value into string.
For embedded systems, we want to
reduce the communication with GDB to a minimum, because GDB itself is
running on a potentially slow processor, with a small bandwidth connection
to the front-end. That is why I am trying to cache all values.
I have two observations:

1. Generally, it's best to run gdb on the same system where you run IDE,
and have it talk to remote stub on the target system. 

2. Even if you run gdb on target, changing varobj format is very fast,
so I'm not sure caching formats is an important thing to do. Did you
actually run into a case where the performance of changing format is

- Volodya

dsdp-dd-dev mailing list

Back to the top