Hi Jonah,
Our product is based on the latest Eclipse and CDT with a delay that is no more than a year.
Regards
Dobrin
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jonah Graham
Sent: Monday, December 9, 2019 2:21 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] [EXTERNAL] Re: Retrieving data from events
Hi Dobrin,
Thank you for speaking up. It is great to hear from the extended CDT community and great to see that many people are reading the emails on the dev list!
At the moment there is no plan to deprecate DSF or GDB's specific implementation, DSF-GDB. At the CDT summit in Nov 2018 a rough plan on the future of Eclipse CDT was created, this involved leveraging new technologies, in particular Debug
Adapters and Languages Servers. Currently I and others are in process of experimenting with that. Of course, anything actively being contributed, maintained, etc will not be deprecated or removed from CDT. This of course includes DSF if the community continues
to maintain it. I hope and expect to be around to maintain it for the coming years, but once debug adapters are working at parity then personally I will be encouraging users and extenders to try that too.
> The link you pointed at looks GDB specific: CDT-GDB-ADAPTER?
That is the GDB specific one, the debug adapter protocol (DAP) is the generic case and the generic implementation in Eclipse is done by LSP4E. So I would hazard to guess that if and when you are looking at DAP for your debugger that it
will have the same relationship to LSP4E/DAP as you do now to DSF. There are some interesting cases to handle - e.g. where should the disassembly view live?
I find this conversation very informative and I am glad you are joining it as it is good to fully understand the lifecycle of extenders. Gidi's case shows that there can be a lag of many many years between changes in CDT and the community
adopting/adapting to these changes.
What version of CDT are you testing & releasing against?
Hi Jonah,
You mentioned deprecating DSF once the new debugger implementation has feature parity.
Do you mean DSF as a framework, or specifically the DSF-GDB implementation?
If I am using DSF for a debugger that is not GDB based, what are my options once DFS Is deprecated?
The link you pointed at looks GDB specific: CDT-GDB-ADAPTER?
Thanks
Dobrin
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jonah Graham
Sent: Monday, December 9, 2019 11:57 AM
To: CDT General developers list.
Subject: [EXTERNAL] Re: [cdt-dev] Retrieving data from events
Hello Gidi,
You may want to listen to the more specialised IContainerResumedDMEvent which has IContainerResumedDMEvent.getTriggeringContexts() if the thread is known. There is a similar one
for suspended, IContainerSuspendedDMEvent which has a getTriggeringContexts, and even a subclass of it called IBreakpointHitDMEvent, which additionally has getBreakpoints. The latter can be passed to IBreakpoints.getBreakpointDMData() for more data (such as
the line and file that was hit).
Although probably not needed at this point, to get the threads within a process use IGDBProcesses.getProcessesBeingDebugged() passing the container context. See my previous email
on how to use it.
PS What is the context of these questions? As CDT is evolving effort is going into a
new debug implementation that is simpler and based on the
debug protocol. However the CDT community needs to know how extenders are actually using CDT in practice, so please let me know. Additionally I would like to know what is it that
made this topic come up now. Is this a dormant project being restarted, or an active project that hasn't upgraded in a long time? The reason I ask is IBM was highly involved in CDT in the past, but the code you are referring to was deprecated years ago and
finally
removed in June 2016. While there is no current plan to remove DSF, it will likely be deprecated once the new debug implementation is at approximate feature parity. Please keep us informed and join us so that your use cases can be considered part of feature
parity.
Hello,
My CDT extension listens to old DebugEvent events and extracts some data. I would like to extract this data with DSF.
The following data is extracted:
- Thread name
Retrieved by ((IThread)DebugEvent.getSource()).getName() (Assuming the the source is IThread)
I found there is IThreadDMContext, which represents a thread. Once you have this context, you can retrieve
IThreadDMData, which has getName() function. I look at the returned value of
IResumedDMEvent.getDMContext().
It returns GDBContainerDMC_7_4 - it extends (eventually) IContainerDMContext, which represents a process, not a thread. I could not find a method which retrieves IThreadDMContext(s) from IContainerDMContext.
Is it possible ?
- Detail - retreived by DebugEvent.getDetail();
I assume that the method IResumedDMEvent.getReason() should supply the information for detail. Is this correct ?
- Line & location - retrieved by IThread.getBreakpoints() and then inspecting the first instance. If getMarker() does not return null, location will be IMarker..getResource().getFullPath().toOSString().
If the breakpoint is ILineBreakpoint, line is retrieved by ILineBreakpoint.getLineNumber().
I found IBreakpointsExtension which retrives IBreakpointDMContext(s) from IExecutionDMContext. From there I assume I should use
IBreakpoints.getBreakpointDMData which seems to have this data. Is this
correct ?
Thanks,
Gidi
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
|
