Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.
 
Mikhail Khodjaiants
ARM Ltd.
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.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com

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

--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Back to the top