CDT-EDC Launching

The team mostly worked on launching EDC debug sessions last sprint. We polished up the Windows launch so terminate shuts everything down correctly and modified the debug agent to shut itself down if no one was connected to it for a short time There are several launch types in Carbide for Symbian debugging that we thouht we might have to clone for EDC. But we've given them the same treatment as Pawel gave the launches in CDT 6.0: defining one standard set of launch types but assigning multiple launch delegates to each one. I wasn't aware you could do this until Pawel implemented this for the CDT launches. It's great for Carbide because we can reuse our existing launch support and just implement an EDC launch delegate. We probably wouldn't ship Carbide with both CDI and EDC launches enabled for the same type, but it will be great for testing and development.

Traditionally most C/C++ launches synchronously start a process and then debugging begins. The simple EDC launches start a process asynchronously and then wait for a process created event from the debug agent. Later we'll support more complex launches: ones that debug multiple processes, target specific DLLs and wait for a process to load them, or simply let you look at stuff on the target platform before debugging anything.

CDT-EDC Baby Steps

Our team runs two week sprints of development activity in pretty standard Agile & Scrum fashion. That seems like a good interval to post updates on our work on the Eclipse Debugger for C/C++ (EDC).

While our intention is to develop EDC as an integral part of the CDT project we haven't committed any of it yet: we want to get more stuff working and the community is too busy getting CDT 6.0 ready to look at it much anyway until after Galileo ships.

I spent much of the last sprint doing bits of high level design work but got back into the code to finish up a story Warren Paul was working on until he left for the hospital.

There has a been a baby boomlet in the CDT committer community over the past several months. Our baby Max arrived back in February. Then Pawel Piech had a new one arrive about a month ago. And last sprint it was Warren's turn.










So I finished up work he was doing on how the EDC debugger connects to TCF agents. We wanted the clients of the agents, usually DSF services, to not know much about TCF concepts like Peers or Channels, but to just be able to ask for "a run control service for Windows debugging." We created a TCFServiceManager and an TCFAgentDescriptor extension point to hide all the details of launching and getting a TCF service from an agent. The extension contains a property list that describes the agent and a delegate that knows how to start it up. The service manager finds the descriptor that matchs the client's request, asks the delegate to launch the agent if it isn't already in the TCF Peer list, then opens a Channel and returns the requested service. The agents get to decide when to shut themselves down, usually when no one has been connected to them for a while.

When an EDC debug session starts we hook up the DSF services to whatever TCF services they need to use. So now the EDC Windows debug agent is started automatically when you start a debug session and shuts down shortly after the session terminates.

The EDC Windows TCF agent is written in C/C++ but we also wanted a reference TCF agent written in Java that can be run in Eclipse or in another instance of the VM. Ling Wang produced one in a previous sprint and just finished adapting it to talk to GDB Server for use by the EDC linux debugger. We'll do something similar for Symbian OS device debugging except it will talk to TRK, the debug agent that runs on the phone.

Each sprint we try to have a simple ramp-up story we can give to another member of the larger Carbide team to help bring them up to speed on EDC. This time it was adding support for writing register values to the EDC Windows debugger (reading them already worked). Stephen Chong came in cold having never seen DSF or TCF but knocked it out in a few days, complete with unit tests.