Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Christelle BURGUERA
Sent: Thursday, June 20, 2013 8:20 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help to implement DSF

Thank you Jason !

Your response was in the spam ….


I’ve extended such similar classes or extension points, I don’t’ have GDBControl, I’ll try to add it.


But for now, I try to add the info thread because now I’ve

Ø  Hello [STxP70 Debug C/C++ Application] GOOD

o   Unknown name [i1] NOT GOOD

§  Thread[1] null (Context…) (Supended : Container) NOT GOOD

Note that I use a “in-house” GDB


Before, with CDI, I’ve extended an org.eclipse.cdt.debug.core.CDebugger and I’ve added in cliInfoThreadCommnd my class to surcharge the info thread.

But with DSF, I don’t get through this class, how can I do ?


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jason Litton
Sent: Wednesday, June 19, 2013 10:48 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help to implement DSF


Hi Christelle,

That's a tough area of the code. We're doing something similar and we've extended:



GdbFinalLaunchSequence (this is HARD to get through)





All of that was necessary to get a DSF launch. You can do a lot of super() stuff in there, but there's a fair bit of customization that needs to take place. Keep asking questions, though. This list can get you pretty good pointers.




From: "Christelle BURGUERA" <Christelle.BURGUERA@xxxxxx>
To: cdt-dev@xxxxxxxxxxx
Sent: Wednesday, June 19, 2013 7:40:33 AM
Subject: [cdt-dev] Help to implement DSF




I work for STMicroelectronics and we have an IDE providing software development tools based on Eclipse and CDT.

Until now, we used the framework CDI, but it is necessary to implement the DSF framework.


I began adding special LaunchDelegate and involving the services LaunchSequence, GDBBackend and other GDBDebugServicesFactory ... My debug starts but I miss the thread info, views Registers, and the GDBConsole Dissassembly are empty ... I'm missing links, extensions ... I do not know what.


I try to debug Eclipse and its DSF to understand how it works but it is very complex and I’m drowning L


Anyone knows a good tutorial, a documentation or a someone who did already this job ???


HELP please !




cdt-dev mailing list


Back to the top