summaryrefslogtreecommitdiff
path: root/docs/lldb-platform-packets.txt
blob: 3258e4c0dd8827264eeace4f9c6ecbec1a355f1d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
Here is a brief overview of the packets that an lldb platform server
needs to implement for the lldb testsuite to be run on a remote
target device/system.

These are almost all lldb extensions to the gdb-remote serial
protocol.  Many of the vFile: packets are described to the "Host
I/O Packets" detailed in the gdb-remote protocol documentation,
although the lldb platform extensions include packets that are not
defined there (vFile:size:, vFile:mode:, vFile:symlink, vFile:chmod:).
Most importantly, the flags that lldb passes to vFile:open: are 
incompatible with the flags that gdb specifies.


//----------------------------------------------------------------------
// QStartNoAckMode
//
// BRIEF
//   A request to stop sending ACK packets for each properly formatted packet.
//
// EXAMPLE 
//   A platform session will typically start like this:
//
//   receive: +$QStartNoAckMode#b0
//   send:    +       <-- ACKing the properly formatted QStartNoAckMode packet
//   send:    $OK#9a
//   receive: +       <-- Our OK packet getting ACKed
//
//   ACK mode is now disabled.

//----------------------------------------------------------------------
// qHostInfo
//
// BRIEF
//   Describe the hardware and OS of the target system
//
// EXAMPLE
//
//  receive: qHostInfo
//  send:    cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5;
//
//  All numbers are base 10, os_version is a string that will be parsed as major.minor.patch.

//----------------------------------------------------------------------
// qModuleInfo
//
// BRIEF
//   Report information about a binary on the target system
//
// EXAMPLE
//  receive: qModuleInfo:2f62696e2f6c73;
//
// FIXME finish this packet description, v. GDBRemoteCommunicationServerCommon::Handle_qModuleInfo


//----------------------------------------------------------------------
// qGetWorkingDir
//
// BRIEF
//   Get the current working directory of the platform stub in
//   ASCII hex encoding.
//
// EXAMPLE
// 
//  receive: qGetWorkingDir
//  send:    2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 



//----------------------------------------------------------------------
// QSetWorkingDir:
//
// BRIEF
//   Set the current working directory of the platform stub in
//   ASCII hex encoding.
//
// EXAMPLE
// 
//  receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 
//  send:    OK

//----------------------------------------------------------------------
// qPlatform_mkdir:
//
// BRIEF
//   Create a directory on the target system.
//
// EXAMPLE
// 
//  receive: qPlatform_mkdir:000001fd,2f746d702f6131
//  send:    F0
//
//  request packet has the fields:
//     1. mode bits in base 16
//     2. file path in ascii-hex encoding
//
//  response is F followed by the return value of the mkdir() call,
//  base 10 encoded.

//----------------------------------------------------------------------
// qPlatform_shell:
//
// BRIEF
//   Run a shell command on the target system, return the output.
//
// EXAMPLE
// 
//  receive: qPlatform_shell:6c73202f746d702f,0000000a
//  send:    F,0,0,<OUTPUT>
//
//  request packet has the fields:
//     1. shell command ascii-hex encoded
//     2. timeout 
//     3. {optional} working directory ascii-hex encoded
//
//  Response is F followed by the return value of the command (base 16),
//  followed by a another number, followed by the output of the command
/   in binary-escaped-data encoding.

//----------------------------------------------------------------------
// qLaunchGDBServer
//
// BRIEF
//   Start a gdbserver process (gdbserver, debugserver, lldb-server)
//   on the target system.
//
// EXAMPLE
// 
//  receive: qLaunchGDBServer;host:<HOSTNAME_LLDB_IS_ON>;
//  send:    pid:1337;port:43001;
//
//  request packet hostname field is not ascii-hex encoded. Hostnames 
//  don't have $ or # characters in them.
//
//  response to the packet is the pid of the newly launched gdbserver,
//  and the port it is listening for a connection on.
//
//  When the testsuite is running, lldb may use the pid to kill off a 
//  debugserver that doesn't seem to be responding, etc.

//----------------------------------------------------------------------
// qKillSpawnedProcess:
//
// BRIEF
//   Kill a process running on the target system.
//
// EXAMPLE
// 
//  receive: qKillSpawnedProcess:1337
//  send:    OK
//
//  The request packet has the process ID in base 10.

//----------------------------------------------------------------------
// qProcessInfoPID:
//
// BRIEF
//   Gather information about a process running on the target
//
// EXAMPLE
// 
//  receive: qProcessInfoPID:71964
//  send:    pid:71964;name:612e6f7574;
//
//  The request packet has the pid encoded in base 10.
//
//  The reply has semicolon-separated name:value fields, two are
//  shown here.  pid is base 10 encoded.  name is ascii hex encoded.
//  lldb-server can reply with many additional fields, but I think
//  this is enough for the testsuite.

//----------------------------------------------------------------------
// qfProcessInfo:
//
// BRIEF
//   Search the process table for processes matching criteria, 
//   respond with them in multiple packets.
//
// EXAMPLE
// 
//  receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65;
//  send:    pid:3500;name:612e6f7574;
//
//  The request packet has a criteria to search for, followed by
//  a specific name.  Other name_match: values include
//  starts_with, ends_with, contains, regex.  You can specify a pid
//  to search for, a uid, all_users, triple, etc etc.  The testsuite
//  only ever searches for name_match:equals.
//
//  The response should include any information about the process that
//  can be retrieved in semicolon-separated name:value fields.
//  In this example, pid is base 10, name is ascii-hex encoded.
//  The testsuite seems to only require these two.
//
//  This packet only responds with one process.  To get further matches to
//  the search, qsProcessInfo should be sent.
//
//  If no process match is found, Exx should be returned.

//----------------------------------------------------------------------
// qsProcessInfo
//
// BRIEF
//   Return the next process info found by the most recent qfProcessInfo:
//   packet.
//
// EXAMPLE
// 
//  Continues to return the results of the qfProcessInfo.  Once all matches
//  have been sent, Exx is returned to indicate end of matches.

//----------------------------------------------------------------------
// vFile:size:
//
// BRIEF
//   Get the size of a file on the target system, filename in ASCII hex.
//
// EXAMPLE
// 
//  receive: vFile:size:2f746d702f61
//  send:    Fc008
//
//  response is "F" followed by the file size in base 16.
//  "F-1,errno" with the errno if an error occurs.


//----------------------------------------------------------------------
// vFile:mode:
//
// BRIEF
//   Get the mode bits of a file on the target system, filename in ASCII hex.
//
// EXAMPLE
// 
//  receive: vFile:mode:2f746d702f61
//  send:    F1ed
//
//  response is "F" followed by the mode bits in base 16, this 0x1ed would 
//  correspond to 0755 in octal.  
//  "F-1,errno" with the errno if an error occurs.

//----------------------------------------------------------------------
// vFile:unlink:
//
// BRIEF
//   Remove a file on the target system.
//
// EXAMPLE
// 
//  receive: vFile:unlink:2f746d702f61
//  send:    F0
//
//  Argument is a file path in ascii-hex encoding.
//  Response is "F" plus the return value of unlink(), base 10 encoding.

//----------------------------------------------------------------------
// vFile:symlink:
//
// BRIEF
//   Create a symbolic link (symlink, soft-link) on the target system.
//
// EXAMPLE
// 
//  receive: vFile:symlink:<SRC-FILE>,<DST-NAME>
//  send:    F0,0
//
//  Argument file paths are in ascii-hex encoding.
//  Response is "F" plus the return value of symlink(), base 10 encoding, twice.

//----------------------------------------------------------------------
// vFile:chmod:
// qPlatform_chmod:
//
// BRIEF
//   Change the permission mode bits on a file on the target
//
// EXAMPLE
// 
//  receive: vFile:chmod:180,2f746d702f61
//  send:    F0
//
//  Arguments are the mode bits to set, base 16, and a file path in 
//  ascii-hex encoding.
//  Response is "F" plus the return value of chmod(), base 10 encoding.
//
//  I don't know why there are two packets for the same thing, v.
//  vFile:chmod:.

//----------------------------------------------------------------------
// vFile:chmod:
//
// BRIEF
//   Change the permission mode bits on a file on the target
//
// EXAMPLE
// 
//  receive: vFile:chmod:180,2f746d702f61
//  send:    F0
//
//  Arguments are the mode bits to set, base 16, and a file path in 
//  ascii-hex encoding.
//  Response is "F" plus the return value of chmod(), base 10 encoding.


//----------------------------------------------------------------------
// vFile:open:
//
// BRIEF
//   Open a file on the remote system and return the file descriptor of it.
//
// EXAMPLE
// 
//  receive: vFile:open:2f746d702f61,00000001,00000180
//  send:    F8
//
//  request packet has the fields:
//     1. ASCII hex encoded filename
//     2. flags passed to the open call, base 16.
//        Note that these are not the oflags that open(2) takes, but
//        are the constant values in enum OpenOptions from lldb's File.h
//     3. mode bits, base 16
//  
//  response is F followed by the opened file descriptor in base 10.
//  "F-1,errno" with the errno if an error occurs.
//
//  COMPATABILITY
//    The gdb-remote serial protocol documentatio defines a vFile:open:
//    packet which uses incompatible flag values, e.g. 1 means O_WRONLY
//    in gdb's vFile:open:, but it means eOpenOptionRead to lldb's
//    implementation.

//----------------------------------------------------------------------
// vFile:close:
//
// BRIEF
//   Close a previously opened file descriptor.
//
// EXAMPLE
// 
//  receive: vFile:close:7
//  send:    F0
//
//  File descriptor is in base 10.
//  "F-1,errno" with the errno if an error occurs.


//----------------------------------------------------------------------
// vFile:pread:
//
// BRIEF
//   Read data from an opened file descriptor.
//
// EXAMPLE
// 
//  receive: vFile:pread:7,1024,0
//  send:    F4;a'b\00
//
//  request packet has the fields:
//     1. file descriptor, base 10
//     2. number of bytes to be read, base 10
//     3. offset into file to start from, base 10
//
//  Response is F, followed by the number of bytes read (base 10), a
//  semicolon, followed by the data in the binary-escaped-data encoding.


//----------------------------------------------------------------------
// vFile:pwrite:
//
// BRIEF
//   Write data to a previously opened file descriptor.
//
// EXAMPLE
// 
//  receive: vFile:pwrite:8,0,\cf\fa\ed\fe\0c\00\00
//  send:    F1024
//
//  request packet has the fields:
//     1. file descriptor, base 10
//     2. offset into file to start from, base 10
//     3. binary-escaped-data to be written
//
//  Response is F, followed by the number of bytes written (base 10)






Finally, the platform must be able to launch processes so that debugserver
can attach to them.  To do this, the following packets should be handled:

QSetDisableASLR
QSetDetachOnError
QSetSTDOUT
QSetSTDERR
QSetSTDIN
QEnvironment
QEnvironmentHexEncoded
A
qLaunchSuccess
qProcessInfo

Most of these are documented in the standard gdb-remote protocol
and/or the lldb-gdb-remote.txt documentation.