From:
cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail
Khodjaiants
Sent: Friday, November 03, 2006
6:24 AM
To: CDT
Debug developers list
Subject: RE: [cdt-debug-dev] CDI
Update Stack Frame
Doug,
All calls to the backend are done in the
none UI threads and are asynchronous. So it doesn't matter if your
call blocks the caller, the caller itself is asynchronous. The problem
with this is if you have a backend that is asynchronous and you want to take
advantage of it. But neither our gdb/mi implementation, neither your
backend (as far as I know) is asynchronous.
Regarding the stack frame handling, I
agree it's a flaw in the current implementation, the change events
for threads should be processed to update the stack. This is one
of the still remaining gdb-isms in the debugger implementation
and one of the issues I would like to address for 4.0.
From:
cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: 02 November 2006 22:03
To: CDT
Debug developers list
Subject: RE: [cdt-debug-dev] CDI
Update Stack Frame
Thanks, Dobrin.
I
had thought of that. However, that only really works when you have a single
thread. For Windows, when the debugger suspend, all threads suspend (actually
all sessions suspend from what I understand). So I want to be able to look at
the stack trace for any of the threads while suspended, but only when requested.
BTW,
the MI implementation suspends the caller until the MI command completes. So
I’ve done that for now too. But that’s synchronous. L.
At
any rate I do have my stack frame generated from the Windows APIs! I’ll
post a screenshot to my blog after I clean it up a little.
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
