Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "TCF/DraftPlan12"

< TCF
(New page: =TCF 1.2 DRAFT plan= ==Compatibility== We will be shooting for a TCF 1.2 version, ie keep API's compatible: * TCF protocol must remain 100% compatible with TCF 1.1 (it's part of the TCF...)
 
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
=TCF 1.2 DRAFT plan=
 
=TCF 1.2 DRAFT plan=
 +
 +
NOTE: The [https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.2.0 TCF 1.2 Plan] is now official.
  
 
==Compatibility==
 
==Compatibility==
Line 15: Line 17:
  
 
==Proposed Themes==
 
==Proposed Themes==
 +
 +
===Robustness and Matrix Coverage===
 +
''Interested Parties:'' All
 +
 +
* We will continue making TCF a rock-solid commercial-grade debug solution and increase its coverage of target architectures and compilers.
 +
** Increase coverage of supported ELF tags and ELF format variants in the symbol and DWARF readers
 +
** Fix defects and increase test coverage
 +
 +
===Improve Unittest coverage at Eclipse.org===
 +
''Interested Parties:'' Wind River, Xilinx
 +
 +
* We have existing unit tests of the Java API running on Eclipse.org, and the agent code is routinely tested at various TCF contributors.
 +
** We'll want to set up an infrastructure for automatically building the TCF C agent, and having it unit-tested on Eclipse.org servers for more transparency of the process.
 +
** We'll strive for an automated integration test of the Java vs. C bits on Eclipse.org servers.
 +
** We'll strive for an automated integration test of the Python API's.
 +
 +
===Remote-controlling Eclipse via TCF===
 +
''Interested Parties:'' Wind River
 +
 +
* TCF has been designed for remote-controlling embedded systems from a host-side tool. But for many end-to-end scripting scenarios, it is also interesting to control the host-side tool from a target or from an external scripting commandline.
 +
** We will contribute a TCF Scripting API that allows any peer to expose functionality to be scripted through a TCF communication channel, along with the ability to discover scriptable commands, help texts, and code completion.
 +
** As exemplary implementation, we will provide an Eclipse scripting server that exposes Eclipse functionality registered through extension point for scripting from the outside
 +
** As exemplary client, we will provide a simple "plain Java" commandline application that allows scripting Eclipse from the outside
 +
** Initial exemplary scripted actions will include show-view, and open-perspective.
 +
 +
===Add PowerPC Debug Support for Linux ptrace===
 +
''Interested Parties:'' Stanislav Yakovlev
 +
 +
* Having PPC debug support in addtion to Intel and ARM would likely further help adoption with embedded distros.
 +
* See {{bug|417126}} and {{bug|417363}} for initial support
 +
 +
===Tracing and Profiling API's===
 +
''Interested Parties:'' Freescale, Xilinx, WindRiver
 +
 +
* There is interest from multiple parties in adding standardized tracing and profiling API's to TCF.
 +
* Adding support for "perf" based profiling on Linux is being discussed.
  
 
===Finish ARM Debug Support for Linux ptrace===
 
===Finish ARM Debug Support for Linux ptrace===
Interested Parties: Wind River
+
''Interested Parties:'' Wind River
  
 
* ARM is an important embedded architecture, TCF should provide good debug support
 
* ARM is an important embedded architecture, TCF should provide good debug support
Line 41: Line 79:
 
* Consider a pre-built package similar to the [https://github.com/mbats/eclipse-buildroot-bundle/wiki Buildroot Eclipse Tools Package]
 
* Consider a pre-built package similar to the [https://github.com/mbats/eclipse-buildroot-bundle/wiki Buildroot Eclipse Tools Package]
 
* TCF is strong in language bindings and scripting. Provide more examples for how to use the TCF Python and Lua bindings.
 
* TCF is strong in language bindings and scripting. Provide more examples for how to use the TCF Python and Lua bindings.
 
===Tracing and Profiling API's===
 
''Interested Parties:'' Freescale, Xilinx, WindRiver
 
 
* There is interest from multiple parties in adding standardized tracing and profiling API's to TCF.
 

Latest revision as of 18:25, 18 December 2013

TCF 1.2 DRAFT plan

NOTE: The TCF 1.2 Plan is now official.

Compatibility

We will be shooting for a TCF 1.2 version, ie keep API's compatible:

  • TCF protocol must remain 100% compatible with TCF 1.1 (it's part of the TCF value proposition)
  • TCF Java API must remain 100% binary compatible (we have clients coding against it)
  • TCF Python and C API should remain 100% compatible (we have clients but this is source compatibility so they can rebuild or use version checks)

Timing

  • TCF 1.2 shall release with Eclipse Luna in June 2014
  • We may want a TCF release earlier, then TCF 1.2 releases earlier and TCF 1.3 comes with Eclipse Luna

Proposed Themes

Robustness and Matrix Coverage

Interested Parties: All

  • We will continue making TCF a rock-solid commercial-grade debug solution and increase its coverage of target architectures and compilers.
    • Increase coverage of supported ELF tags and ELF format variants in the symbol and DWARF readers
    • Fix defects and increase test coverage

Improve Unittest coverage at Eclipse.org

Interested Parties: Wind River, Xilinx

  • We have existing unit tests of the Java API running on Eclipse.org, and the agent code is routinely tested at various TCF contributors.
    • We'll want to set up an infrastructure for automatically building the TCF C agent, and having it unit-tested on Eclipse.org servers for more transparency of the process.
    • We'll strive for an automated integration test of the Java vs. C bits on Eclipse.org servers.
    • We'll strive for an automated integration test of the Python API's.

Remote-controlling Eclipse via TCF

Interested Parties: Wind River

  • TCF has been designed for remote-controlling embedded systems from a host-side tool. But for many end-to-end scripting scenarios, it is also interesting to control the host-side tool from a target or from an external scripting commandline.
    • We will contribute a TCF Scripting API that allows any peer to expose functionality to be scripted through a TCF communication channel, along with the ability to discover scriptable commands, help texts, and code completion.
    • As exemplary implementation, we will provide an Eclipse scripting server that exposes Eclipse functionality registered through extension point for scripting from the outside
    • As exemplary client, we will provide a simple "plain Java" commandline application that allows scripting Eclipse from the outside
    • Initial exemplary scripted actions will include show-view, and open-perspective.

Add PowerPC Debug Support for Linux ptrace

Interested Parties: Stanislav Yakovlev

  • Having PPC debug support in addtion to Intel and ARM would likely further help adoption with embedded distros.
  • See bug 417126 and bug 417363 for initial support

Tracing and Profiling API's

Interested Parties: Freescale, Xilinx, WindRiver

  • There is interest from multiple parties in adding standardized tracing and profiling API's to TCF.
  • Adding support for "perf" based profiling on Linux is being discussed.

Finish ARM Debug Support for Linux ptrace

Interested Parties: Wind River

  • ARM is an important embedded architecture, TCF should provide good debug support
    • Single-stepping will need some code that involves parsing opcodes

Collaborate with Linux Distro Builders

Interested Parties: Wind River

  • For widespread adoption, a TCF agent should come out-of-the-box with Yocto, Buildroot, Raspbian and potentially other Linux distros.

Collaborate with gdb and Multicore Association

Interested Parties: Wind River, Xilinx

  • gdb is very strong thanks to its rich and well-known command-line and scripting support; but it has performance problems on multicore embedded systems since the "gdbserver" protocol is very limited. The gdb community is thinking about a new remote protocol. TCF seems to exactly match their needs. Collaboration should be considered.
  • The Multicore Association TIWG is working on a generic protocol for tooling. TCF seems to be a very good match for their needs. Continue exchange and collaboration.

Further Improve Usability

Interested Parties: Wind River

  • We'll want to further improve the out-of-box experience and usability for TCF-based products.
  • Add more HOWTO's and out-of-box documentation instructions like the Raspberry Pi HOWTO
  • Consider a pre-built package similar to the Buildroot Eclipse Tools Package
  • TCF is strong in language bindings and scripting. Provide more examples for how to use the TCF Python and Lua bindings.

Back to the top