RE: [dsdp-tm-dev] TCF feedback

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

Title: TCF feedback

Hi Ken,

 

Thanks for the review and the feedback.  See replies below

 

From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Ryall
Sent: Monday, April 28, 2008 1:41 PM
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: [dsdp-tm-dev] TCF feedback

 

Hi,

I’ve been reviewing all of the material I can find about the target communications framework (TCF) project. Looks like a nice job overall, but my understanding remains fuzzy in a few areas:

What if you had multiple agents running on the same host? They would need to use different ports and so perhaps would not be discoverable? And if they were not discoverable is there some way to connect to them directly?

We solve this issue by having the first TCF server to use the “standard TCF” port number, we call this the discovery master, and all subsequent TCF servers on the same host will use a dynamic port number.  The subsequent TCF servers will connect to the discovery master to publish their discovery information.  When the discovery master disappears for any reason then one of the other TCF servers will try to become the master.

It looks like you might have agents providing various services running on the host or target or both. Some of the services in the reference agent (symbols, expressions) seem like they are things you would do on the host while others (run control, memory, registers) you would do on the target. When debugging on the host only all those could be rolled into one agent but otherwise it seems like you would need to split them up.

You are right, the agent prototype does implement some things that would normally be done on the host e.g. symbols/line number information.  This was done to prototype the service and to test the DSF integration.  Clearly in a resource constrained embedded system you would not implement those services on the target, but the idea is that the same service interface would be use, so clients would not see any difference.

I understand the reference agent is written in plain vanilla C code to facility scaling down to simple devices. But if I were writing an agent that was intended to live host side or for more robust targets I would prefer to write it in C++. Are they any issues with writing an agent in C++?

I don’t see any technical issues with writing an agent in C++.  We just chose to use C because we need to be able to be able to run the agent in the kernel and on interrupt level and for this C is more suitable.

It seems like if you currently had a debug agent on a target you could convert it into a TCF agent and just revise the host side stuff that talks to it. That would open it up to other tools that support the TCF protocol. Do I have that right?

Yes, the implementation should not matter as long as the protocol is followed.  It would probably be good to have a protocol validation test suite to make sure multiple implementations are functional.

Thanks,

Felix

Thanks - Ken