Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Freeze invisible GDB variable objects

On 08/14/2014 12:38 PM, Pascal Rapicault wrote:
On which criteria would the framework emit those commands?
Not quite sure on what your question focuses. But beside the question how to implement it, in the ideal world, CDT would behave like that (IMHO):

Assume we're in the Expression View, having two root items both of type class/struct and both contain some members, like this:

=======================================  (This is the view top border)
|   |_ MyObject             | {...}   |  (assume varobj name="var1")
|         |_  m_Member1| value 1 | (assume varobj name="var1.m_Member1")
|         |_  m_Member2     | value 2 |  ...
|         |_  m_Member3     | value 3 |
|         |_  m_Member4     | value 4 |
|   |_ MyOtherObject        | {...}   | (assume varobj name="var2")
|         |_  m_Array1[20];| {...}   | (assume varobj name="var2.m_Array1")
|         |_  m_OthrMember2 | value 2 |
|         |_  m_OthrMember3 | value 3 |
======================================= (This is the view bottom border)
|_ m_OthrMember5(invisible - therefore don't get value fromembedded target) |_ m_OthrMember6(invisible- therefore don't get value from embedded target) |_ m_OthrMember7(invisible- therefore don't get value from embedded target)

In that situation, there are more members than can be shown without scrolling down. Therefore, from "m_OthrMember4" (which is hidden below the bottom border) and further below, no more members are visible. Therefore, it is a waste of resources to refresh them, as CDT/GDB is doing it today. This especially hurts if a struct contains hundreds of members (e.g. a struct that represents hardware registers with hundreds or even thousands of members which can easily cumulate to a total size of 1MByte which happen to be refreshed on every debug event).Btw: this happens because CDT executes a '-var-update 1 var1' and '-var-update 1 var2' on every debugging event. And because CDT didn't freeze any members, GDB will just update all members, resulting in reading all the memory of the struct from the (embedded) target, e.g. 1MByte(!).

If you're question focus on the "how to notice when a member appears or disappears" from the visible range, e.g. because the user is scrolling and the like: Well, that's exactly what my initial post tries to find out.

Right now, as I'm writing this, I realize that CDT already does something like that. E.g. when initially expanding a struct (e.g. MyOtherObject), then CDT does only execute '-var-evaluate-expression' on the visible items (m_Array1, OthrMember2and m_OthrMember3in this example). Then, when I scroll down in the Expression View, so that m_OthrMember4 appears, CDT executes another "-var-evaluate-expression" for var2.m_OthrMember4, right when that member starts appearing. I might study that code to find out more...


On 14/08/2014 10:52 AM, Raphael Zulliger wrote:

To increase debugging performance when having huge data structures in Variable/Expression View etc., I'd like to make extend CDT with GDB's "-var-set-frozen" or "-var-set-update-range" features (see

I'm still quite unfamiliar with the ViewModel concept and how it finally links to the UI. Therefore, can someone point me towards a good starting point regarding: How can I know which elements in the Variable View, Expression View are currently visible? (i.e. if there are 1000 members in a struct, the view will at most show a few dozens, depending on the height of the view - all others are invisible). How could I get notified about changes (e.g. the user scrolls down the list)?

Any idea/hint would highly be appreciated!

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top