|
70
|
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>
|