[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-tcf-dev] RE: TCF Reference Agent
|
I'm still trying to figure out what the right architecture should be. The promise of TCF is to be able to have different tools (and Python scripts are a great example) work with different agents through a standardized protocol. As Martin and Pawel presented at EclipseCon, having a collection of agents, i.e. ones on the host to do things like symbol management and ones on the target to handle debug and data collection, are part of our goal here. So, in that sense, I do agree that dwarf symbol reading should be done in the agent.
My gut is telling me that we should merge the EDC agents and the TCF reference agent into one and accompany that with a restructuring to ensure it's easy to add and replace services in the agent and to retarget the agent to new OSes/FW environments. But I'm also wary that different agents may have different implementation requirements so my head isn't 100% sold that that is the right approach.
At any rate, it's getting time for us to start working together on a vision for TCF and a roadmap to get there. With your help, we should put together a plan for the plan.
On Tue, Apr 27, 2010 at 7:23 AM, Emilio Monti
<Emilio.Monti@xxxxxxx> wrote:
Hi Doug,
Currently, we are investigating different possibilities. Adopting the
reference TCF agent is one of them.
In particular, we are also looking for a module handling the DWARF debug
information.
Is the agent's DWARF module going to be further developed and supported,
or is it going to be put aside in favour of the EDC one?
We have recently discovered a bug in the agent not correctly handling
the endianness of the symbol table entries. (We are going to open a new
bug in Bugzilla for that).
There are two reasons why we would favour keeping the DWARF module in
the debug agent:
* Our FW developers would like to have all the debug capabilities
available in a Python shell without the need to open the IDE. The TCF
protocol looks promising to achieve that (we already have a first Python
implementation of the TCF protocol).
* We would like to use Python scripts to write automated tests to
stress all the debug capabilities.
Cheers,
Emilio Monti
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
