Re: [cdt-dev] DSF/GDB: How can I refresh the debug context?

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi Mikhail,

in the case of clearing a cache in a service itself can be done by triggering an event when 'target-download' is finished and having MIStack listen for it.
If you then need to kick the Debug view to read the new stack frame, then the debug view will have to listen to that event too.

So it seems we will keep on adding events after events to trigger the Debug view to refresh...  Maybe it is warranted to address this with a more generic
framework/event.  Maybe in cases like these, which don't happen often, we don't need to be as efficient as a SuspendedEvent and simply 
refresh the entire view...

I suggest opening a bug for this and discussing the design details.

Thanks

Marc


________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants [mikhailkhod@xxxxxxxxxxxxxx]
Sent: June 22, 2011 8:53 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] DSF/GDB: How can I refresh the debug context?

On 16/06/2011 3:26 PM, Marc Khouzam wrote:
A refreshEvent was discussed but I felt it was too generic an event.  Normally, you would create a new event or events, and would update the VM node.  But I realize it is a lot of work and it would be much nicer to simply issue an event that will refresh the views.

Maybe someone more knowledgeable about the VM nodes can give their input?   Pawel maybe :-)

I've done something not as cleanly as I should have for tracepoint visualiztion that you can look at, which
refreshes the Debug view on an couple of Trace events.  Look at LaunchVMProvider and event
ITracingStartedDMEvent.  It does not use the deltas but simply refreshes the view.  I would like
to clean that up in the next release though.

You can also look at MITracepointSelectedEvent which pretends to be a breakpointHitEvent to trigger
a SuspendedEvent and refresh the views.

Marc

________________________________
Marc,

I have run into a similar issue.
Running 'target-download" command changes the stack information but the stack frames in the Debug view can not be updated because the current context (the top stack frame) is cached in "MIStack" and needs to be reloaded.
The same problem will appear in the case when the symbol table of a library is loaded manually. We had a request to fix it for CDI.

Shouldn't we add something like 'StackChangedEvent' to 'IStack'? What do you think?

Thanks,
Mikhail