|Re: [cdt-dev] Help to implement DSF|
When things don't behave properly in the Debug view, it means one of the DSF services is not returning the information you are expecting.
For example, if the process says "Unknown name" it means that ContainerVMNode.updatePropertiesInSessionThread(), which tries to fill that information, is not getting the right name from IProcesses.getExecutionData().
Similarly if the thread name is 'null', you can look at ThreadVMNode.updatePropertiesInSessionThread() and IProcesses.getExecutionData()
Here are a couple of things I find useful working with DSF-GDB:
- *VMNode classes fill the data of the view using the DSF services.
updatePropertiesInSessionThread() is for labels
updateElementsInSessionThread() is for actual element (each thread for example)
You can start debugging those methods and follow them into the DSF service calls
- Classes extending IDsfService and AbstractDsfService are the different DSF services CDT provides. They deal with getting the data from GDB.
You can look at the interface of a service, e.g., IProcesses/IMIProcesses/IGDBProcesses for the different things the service provides.
You can then debug the call in question, to see why it is not finding the right information from GDB.
- When looking at DSF services, take the time to figure out the hierarchy and which class is used for which version of GDB. You don't want
to modify one class only to realize it is not used for that GDB version :)
- GdbLaunchDelegate is the DSF-GDB delegate associated with every CDT launch configuration type. This is the entry point of every launch.
You can either define a new configuration type, or you can add a new delegate to the exiting config types to use your own.
- GdbDebugServicesFactory is used to instantiate the different DSF services based on GDB versions. It can be useful to set breakpoints
there to make sure you are using the right service version, or your own service implementation. Don't forget to update this class if you
are overriding a service.
- FinalLaunchSequence is used to configure GDB the way you need for your type of session. As Jason said, this is tricky to extend, but
we've put in some effort to make it easier than before...
- Be careful to focus on the MI command classes found in org.eclipse.cdt.dsf.mi.service.command. They have the exact same names
as the CDI ones (because DSF was not part of CDT at the start). We do not use the ones in org.eclipse.cdt.debug.mi for DSF.
- the fact that you use an in-house GDB may require some tweaks. If that GDB answers differently to some commands, you will have
to compensate by overriding the relevant MI* commands.
- You can use CommandFactory to change some details about an MI command, but if that is not enough, you will need to change the
DSF service itself to use a different MI command (or use it in a different way)
- about cliInfoThreadCommnd, for newer GDB versions, we use MIThreadInfo in org.eclipse.cdt.dsf.mi.service.command.
- if you see a view with a title in italic, it often means there is a missing rm.done() call, probably in a DSF service implementation you
changed. In that case the view does not get all the info it is waiting for and 'hangs'.
If you didn't find things difficult at the start, you would have the been one of the very few. I struggled a lot at first.
But once you get the pattern down, things should pick up pretty quickly.
I hope the above pointers help.
Back to the top