|
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
|
2 <HTML> |
|
3 <head> |
|
4 <title>TCF Agent Porting Guide</title> |
|
5 </head> |
|
6 |
|
7 <body lang='EN-US'> |
|
8 |
|
9 <h1>TCF Agent Porting Guide</h1> |
|
10 |
|
11 <p> |
|
12 Copyright (c) 2009 Wind River Systems, Inc. Made available under the EPL v1.0 |
|
13 </p> |
|
14 <p> |
|
15 Direct comments, questions to the <a href="mailto:dsdp-tcf-dev@eclipse.org">dsdp-tcf-dev@eclipse.org</a> mailing list |
|
16 </p> |
|
17 |
|
18 <h2>Table of Contents</h2> |
|
19 <ul> |
|
20 <li> |
|
21 <a href='#Introduction'>Introduction</a> |
|
22 </li> |
|
23 <li> |
|
24 <a href='#Customizing'>Customizing and Porting TCF Agent</a> |
|
25 </li> |
|
26 <li> |
|
27 <a href='#NewOS'>Porting TCF Agent to a New OS Platform</a> |
|
28 </li> |
|
29 <li> |
|
30 <a href='#NewCPU'>Porting TCF Agent to a New CPU Type</a> |
|
31 </li> |
|
32 <li> |
|
33 <a href='#NewExeFile'>Adding Support For a New Executable File Format</a> |
|
34 </li> |
|
35 <li> |
|
36 <a href='#NewDebugData'>Adding Support For a New Debug Data Format</a> |
|
37 </li> |
|
38 <li> |
|
39 <a href='#NewTransport'>Adding Support For a New Communication Trasport</a> |
|
40 </li> |
|
41 </ul> |
|
42 |
|
43 <h2> |
|
44 <a name='Introduction'>Introduction</a> |
|
45 </h2> |
|
46 |
|
47 <p> |
|
48 TCF Agent is a lightweight reference implementation of TCF protocol that supports basic debugging and other TCF services. |
|
49 It is written in C and can be used for remote debugging of software written for Linux, Windows XP or VxWorks. |
|
50 See <a href='TCF Getting Started.html'>TCF Getting Started</a> for instructions on how to get the source code and build the agent. |
|
51 </p> |
|
52 |
|
53 |
|
54 <h2> |
|
55 <a name='Customizing'>Customizing and Porting TCF Agent</a> |
|
56 </h2> |
|
57 |
|
58 <p> |
|
59 It is important to know concurrency model used by the agent code before making any changes. |
|
60 Most of the agent code is event driven: it has a main loop that retrieves events from an event queue and executes them sequentially by calling event handlers by a single thread. |
|
61 Single threaded event driven design provides good level of concurrency (equivalent to cooperative multithreading), while greatly reduces need for synchronization - |
|
62 each event dispatch cycle can be viewed as fully synchronized atomic operation. |
|
63 </p> |
|
64 |
|
65 <p> |
|
66 Event driven code should avoid long running or potentially blocking operations in event handlers since they can stop all event processing for indefinite time. |
|
67 Such operations should use asynchronous APIs (like POSIX Asynchronous I/O), or should be performed by background threads. |
|
68 Treat background threads with extreme caution - agent data structures are not intended for multithreaded access. |
|
69 Background thread scope should be limited to a single module and it should not call agent public APIs. |
|
70 Instead they should communicate with the rest of the code by posting events. |
|
71 </p> |
|
72 |
|
73 <p> |
|
74 An event is essentially a function pointer (a call-back) that points to event handler, plus a data pointer. |
|
75 Call-backs are also used throughout the agent code to subscribe listeners for various state change notifications. |
|
76 Using events and call-backs, as a design principle, is also known as inversion of control. |
|
77 Note that, in general, inversion of control is not compatible with traditional multithreaded programming model that used mutexes to protect shared data from racing conditions. |
|
78 </p> |
|
79 |
|
80 <p> |
|
81 Most of TCF agent configuration is done at compile time. |
|
82 Conditional compilation statements in the source code assume that both the agent and inferior code will run on same OS platform and |
|
83 on same CPU type that were used to build the agent. |
|
84 Building an agent that can run on one machine while controlling execution of code on another machine might be possible, but not fully supported at this time. |
|
85 </p> |
|
86 |
|
87 <p> |
|
88 Header file <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/config.h'>config.h</a> contains macro definitions that control agent configuration. |
|
89 All C files in the agent code include <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/config.h'>config.h</a> before other header files. |
|
90 Individual services or features can be enabled or disabled by changing definitions in the file. |
|
91 Also, macro values can be overwritten by using -D option in C compiler command line. |
|
92 Agent <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/Makefile'>Makefile</a> contains additional logic that makes it even more convenient to build different agent configurations. |
|
93 </p> |
|
94 |
|
95 <p> |
|
96 It should be much easier to port the agent if you don't need all TCF services. |
|
97 For example, for RSE integration you only need File System, System Monitor and Processes services, |
|
98 so you can disable all other services by editing <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/config.h'>config.h</a>. |
|
99 </p> |
|
100 |
|
101 <p> |
|
102 It is better to create a separate directory with alternative versions of |
|
103 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/config.h'>config.h</a>, |
|
104 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/context.h'>context.h,</a> |
|
105 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/context.c'>context.c,</a> |
|
106 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/Makefile'>Makefile,</a> |
|
107 etc., instead of editing original files. |
|
108 The idea is that Makefile will search that directory first, and if a file not found there, it will search original agent sources. |
|
109 See <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/examples/org.eclipse.tm.tcf.examples.daytime.agent'>examples/org.eclipse.tm.tcf.examples.daytime.agent</a> |
|
110 for an example of a custom TCF agent. |
|
111 Of course, if changes are generic enough to be useful for other ports, then it is better to change code in the main directory. |
|
112 </p> |
|
113 |
|
114 <p> |
|
115 Please, consider contributing your changes of the source code back to eclipse.org. |
|
116 </p> |
|
117 |
|
118 <h2> |
|
119 <a name='NewOS'>Porting TCF Agent to a New OS Platform</a> |
|
120 </h2> |
|
121 |
|
122 <p> |
|
123 In order to improve portability, instead of using non-portable native OS calls, agent code uses POSIX APIs whenever possible. |
|
124 When a POSIX API is not available for particular platform, and it can be easily emulated, it is done in mdep.h/mdep.c files. |
|
125 For example, mdep.h/mdep.c contains emulation of POSIX Threads for Win32, since the API is not available with Microsoft C compiler. |
|
126 API emulation does not have to be complete, it only needs to implement functionality that is used by the agent. |
|
127 </p> |
|
128 |
|
129 <p> |
|
130 When it is not possible or not feasible to use portable POSIX APIs, the agent code contains conditional compilation statements that |
|
131 use well known macros like WIN32, __CYGWIN__, __MINGW32__, etc. Such places might require editing when porting to a new OS. |
|
132 </p> |
|
133 |
|
134 <h2> |
|
135 <a name='NewCPU'>Porting TCF Agent to a New CPU Type</a> |
|
136 </h2> |
|
137 |
|
138 <p> |
|
139 Searching TCF agent source code for __i386__ is a good way to find all places where the source code depends on CPU type. |
|
140 </p> |
|
141 |
|
142 <p> |
|
143 There are several files in the code that might need changes in order to support a new CPU type: |
|
144 </p> |
|
145 |
|
146 <dl> |
|
147 <dt> |
|
148 <b> |
|
149 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/context.c'>context.c</a> |
|
150 </b> |
|
151 </dt> |
|
152 <dd> |
|
153 The module provides low level debugger functionality: attach/detach, suspend/resume, single step, memory read/write. |
|
154 It uses OS debug APIs to do its job. Most of the code does not depend on CPU type, however, single stepping is not always directly |
|
155 supported by OS, and its implementation needs to be reviewed and changed to support new CPU type. |
|
156 </dd> |
|
157 <dt> |
|
158 <b> |
|
159 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/dwarfexpr.c'>dwarfexpr.c</a> |
|
160 </b> |
|
161 </dt> |
|
162 <dd> |
|
163 The module implements evaluation of <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> expressions. |
|
164 The module is used only if the agent is built to support |
|
165 <a href='http://en.wikipedia.org/wiki/Executable_and_Linkable_Format'>ELF</a> executable file format and |
|
166 <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> debugging data format. |
|
167 No need to change the module if <a href='http://en.wikipedia.org/wiki/Executable_and_Linkable_Format'>ELF</a> or |
|
168 <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> support is not required. |
|
169 <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> expressions can have references to CPU registers. |
|
170 Register access code needs to be changed to support new CPU type. |
|
171 Note that different compilers can use different numbers to identify same registers of same CPU. |
|
172 </dd> |
|
173 <dt> |
|
174 <b> |
|
175 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/registers.c'>registers.c</a> |
|
176 </b> |
|
177 </dt> |
|
178 <dd> |
|
179 The module implements <a href='TCF Service - Registers.html'>Registers service</a>. The code has static variable "regs_index" that contains a table of CPU registers. |
|
180 The table holds names, offsets and sizes of CPU registers. Offset and size define location of register data in REG_SET structure, |
|
181 which represents snapshot of register values of an execution context. Definition of the variable needs to be changed to support new CPU type. |
|
182 </dd> |
|
183 <dt> |
|
184 <b> |
|
185 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/stacktrace.c'>stacktrace.c</a> |
|
186 </b> |
|
187 </dt> |
|
188 <dd> |
|
189 The module implements <a href='TCF Service - Stack Trace.html'>Stack Trace service</a>. |
|
190 The module contains "trace_stack" function that creates stack trace by walking a stack of an executable context. |
|
191 Stack trace data format is defined by two struct declarations: StackTrace and StackFrame. |
|
192 The data structure is generic, however the code that created the data structure is CPU dependand. |
|
193 Alternative version of "trace_stack" function needs to be provided to support new CPU type. |
|
194 </dd> |
|
195 </dl> |
|
196 |
|
197 <h2> |
|
198 <a name='NewExeFile'>Adding Support For a New Executable File Format</a> |
|
199 </h2> |
|
200 |
|
201 <p> |
|
202 For source level debugging TCF agent needs to understand executable file format. |
|
203 Source level debugging is supported by providing two services: Symbols and Line Numbers. |
|
204 The services are optional, and if they are disabled no support for executable file format is needed. |
|
205 At this time the agent supports <a href='http://en.wikipedia.org/wiki/Executable_and_Linkable_Format'>ELF (Executable and Linking Format)</a> |
|
206 and <a href='http://en.wikipedia.org/wiki/Portable_Executable'>PE (Portable Executable)</a> files. |
|
207 ELF is very popular format in Unix-like and embedded systems, and PE is used in Windows operating systems. |
|
208 </p> |
|
209 |
|
210 <p> |
|
211 ELF supported in the agent is developed from scratch, has no external dependences, and is available in source form as part of the agent source code. |
|
212 The code might require changes to support a particular flavor of ELF. |
|
213 Probably the most tricky part of the code is interface to the system loader. |
|
214 The agent needs to know when an ELF file is loaded into or removed from target memory so it can update symbol tables and breakpoints. |
|
215 For that it plants an internal (not visible to clients) breakpoint (aka eventpoint) inside system loader code. |
|
216 The breakpoint allows agent to intercept control every time an ELF file is loaded or unloaded. |
|
217 </p> |
|
218 |
|
219 <p> |
|
220 PE support in the agent is implemented by using DBGHELP.DLL. This DLL is included in Windows operating system. |
|
221 However, older versions of the DLL might not provide all necessary functionality. |
|
222 To obtain the latest version of DBGHELP.DLL, go to <a href='http://www.microsoft.com/whdc/devtools/debugging/default.mspx'> |
|
223 http://www.microsoft.com/whdc/devtools/debugging/default.mspx</a> and download Debugging Tools for Windows. |
|
224 </p> |
|
225 |
|
226 <p> |
|
227 Support for a completely new file format would require to develop alternative versions of symbols_xxx.c and linenumbers_xxx.c files. |
|
228 See <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/symbols_elf.c'>symbols_elf.c</a> |
|
229 and <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/linenumbers_elf.c'>linenumbers_elf.c</a> |
|
230 as example implementation of the services. |
|
231 </p> |
|
232 |
|
233 <h2> |
|
234 <a name='NewDebugData'>Adding Support For a New Debug Data Format</a> |
|
235 </h2> |
|
236 |
|
237 <p> |
|
238 For source level debugging TCF agent needs to understand debug data format. |
|
239 Debug data is usually reside in a section of an executable file, so the file format should be supported, see <a href='#NewExeFile'>Adding Support For a New Executable File Format</a>. |
|
240 At this time the agent supports <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> and |
|
241 <a href='http://en.wikipedia.org/wiki/Portable_Executable'>PE (Portable Executable)</a> debug data formats. |
|
242 <a href='http://en.wikipedia.org/wiki/DWARF'>DWARF</a> support is implemented as part of the agent source code, |
|
243 and <a href='http://en.wikipedia.org/wiki/Portable_Executable'>PE</a> data is accessed using DBGHELP.DLL, which is included in Windows operating system. |
|
244 </p> |
|
245 |
|
246 <h2> |
|
247 <a name='NewTransport'>Adding Support For a New Communication Transport</a> |
|
248 </h2> |
|
249 |
|
250 <p> |
|
251 Current agent code uses TCP/IP as the transport protocol to open communication channels. |
|
252 The agent code can be easily modified to support other transport protocols, like UDP, USB, etc. |
|
253 </p> |
|
254 |
|
255 <p> |
|
256 Files <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/channel_tcp.h'>channel_tcp.h</a> |
|
257 and <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/channel_tcp.c'>channel_tcp.c</a> provide support for TCP/IP transport. |
|
258 To support another protocol one would need to develop similar code using TCP support as an example. |
|
259 </p> |
|
260 |
|
261 <p> |
|
262 Adding new transport would also require to modify functions channel_server() and channel_connect() in |
|
263 <a href='http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent/channel.c'>channel.c</a>. |
|
264 </p> |
|
265 </body> |
|
266 </HTML> |