From:
cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexiev, Dobrin
Sent: Thursday, November 02, 2006
4:53 PM
To: CDT
Debug developers list; CDT General
developers list.
Subject: RE: [cdt-debug-dev] CDI
Update Stack Frame
Doug,
In our debugger we
didn’t propagate the suspend event in Eclipse until we got the stack
frame changed event from our back end and cached all stack frames.
We had to introduce a
little state machine for that. Hated -> Stack List Ready -> Running.
Also, in rare case when
we wanted some stuff updated while the target was suspended we were firing
resume and then immediately suspend.
These two things worked
for us on Eclipse 3.1 and 3.2.
Again, we were
implementing CDI interfaces.
Regards
Dobrin
From:
cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Thursday, November 02, 2006
4:22 PM
To: CDT
General developers list.; CDT Debug
developers list
Subject: [cdt-debug-dev] CDI
Update Stack Frame
Hey gang, I’m putting the claim that the CDI can
handle asynchronous calls to the test.
For my Windows debugger integration, I have to process all
calls to the Windows API through a single thread. I have thus created a command
posting architecture (I guess it’s similar to the CDI/MI interface).
Now, when the framework calls any of the getStackFrame*
methods and I don’t have the current stack frame, I dispatch a call to my
thread and return 0/null. The hope is that when I do finally get the stack
frame I can dispatch an event of some sort to let the framework know I have the
stack information.
I thought a changed event on the thread would do the trick,
but I see the implementation for handling the event is empty (and besides, it
didn’t work J). Is there another
way?
Thanks,
Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com