Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
TCF/DraftPlan12
< TCF
Contents
- 1 TCF 1.2 DRAFT plan
- 1.1 Compatibility
- 1.2 Timing
- 1.3 Proposed Themes
- 1.3.1 Robustness and Matrix Coverage
- 1.3.2 Improve Unittest coverage at Eclipse.org
- 1.3.3 Remote-controlling Eclipse via TCF
- 1.3.4 Add PowerPC Debug Support for Linux ptrace
- 1.3.5 Tracing and Profiling API's
- 1.3.6 Finish ARM Debug Support for Linux ptrace
- 1.3.7 Collaborate with Linux Distro Builders
- 1.3.8 Collaborate with gdb and Multicore Association
- 1.3.9 Further Improve Usability
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.