Hi Gidi,
Thank you for the background on your project.
I think there are still some terms that need better defining - sorry if some of this is already understood.
JDT - Java Development Tools - in the context of this conversation the JDT provides an implementation of the Eclipse Debug model (org.eclipse.debug.core.model.IDebugElement and friends)
CDI - C Debugger Interface - this was part of CDT and is the now removed implementation of the Eclipse Debug model
DSF - (and DSF-GDB specifically) - Debug Services Framework for GDB - this is the current debugger implementation in CDT. It (sort of) implements the Eclipse Debug model, it just does it asynchronously, so the synchronous APIs are not supported.
As far as I can tell, you were simply using CDI when referring to the Eclipse Debug model - I fear I added to this confusion in our earlier conversations.
To make matters somewhat complicated, DSF, when first implemented, was designed to replace CDI, however as many parts of CDI were reusable, those items still remain in the code with the CDI name. Best example of that is breakpoints, the breakpoint model that DSF uses is the same as CDI used to use, so classes like ICBreakpoint and CDIDebugModel continue to be used for DSF*.
On to your question:
> I have a follow
up question regarding breakpoints. My code is required to add a breakpoint
when application is starting a debug session. It is also required to listen
to the events when breakpoint is added and removed.It uses org.eclipse.debug.core.IBreakpointManager
for listening to events and it uses org.eclipse.cdt.debug.core.CDIDebugModel
(functionBreakpointExistsand createFunctionBreakpoint). Is it ok to still
use this API with CDT-DSF or should it be replaced with code in DSF API
?
Yes it is ok, use that. Wherever you can use org.eclipse.debug API you are in the best position. As mentioned above, CDIDebugModel applies to DSF so it should be correct for what you are doing.
> Regarding the
new debug implementation, I'll be happy to test it with our code, when
I have some spare time. Where can I find instructions how to prepare Eclipse
environment which uses it ?
Wonderful - please keep an eye on this mailing list, while early versions of the code are available in the 9.10 release (due Wednesday) it isn't properly announced yet. There are key items still missing, and in your use case I suspect function breakpoints are high on the list of missing items!
HTH,
Jonah
* Arguably these classes, especially the ones with CDI in the name, should have been renamed from a consistency standpoint when CDI was removed.
Hello Jonah,
Thanks for your
reply. My project is active, but it has not been upgraded in a long time.
My current work is to align it with DSF. My plugins supports both CDT and
JDT. If I understand correctly, for JDT the CDI API is still relevant,
so I need to supply DSF support for CDT projects (which no longer support
the option of launching debug session with old CDI) and still keep the
JDT support which is based on CDI. I need to listen to events related to
start\end debug sessions and also when session is suspended\resumed and
I need to supply information about these events. I also need to be able
to suspend\resume\terminate sessions. All this was covered in my previous
questions.
I have a follow
up question regarding breakpoints. My code is required to add a breakpoint
when application is starting a debug session. It is also required to listen
to the events when breakpoint is added and removed.
It uses org.eclipse.debug.core.IBreakpointManager
for listening to events and it uses org.eclipse.cdt.debug.core.CDIDebugModel
(functionBreakpointExistsand createFunctionBreakpoint). Is it ok to still
use this API with CDT-DSF or should it be replaced with code in DSF API
?
Regarding the
new debug implementation, I'll be happy to test it with our code, when
I have some spare time. Where can I find instructions how to prepare Eclipse
environment which uses it ?
Thanks,
Gidi
From:
Jonah
Graham <jonah@xxxxxxxxxxxxxxxx>
To:
"CDT
General developers list." <cdt-dev@xxxxxxxxxxx>
Date:
12/09/2019
06:57 PM
Subject:
[EXTERNAL]
Re: [cdt-dev] Retrieving data from events
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
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 newdebug 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 removedin 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.
HTH,
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
On Mon, 9 Dec 2019 at 10:30, Gidi Gal1
<GGal1@xxxxxxxxxx>
wrote:
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
_______________________________________________
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
