1 LLDB has added new GDB server packets to better support multi-threaded and
2 remote debugging. Why? Normally you need to start the correct GDB and the
3 correct GDB server when debugging. If you have mismatch, then things go wrong
4 very quickly. LLDB makes extensive use of the GDB remote protocol and we
5 wanted to make sure that the experience was a bit more dynamic where we can
6 discover information about a remote target without having to know anything up
7 front. We also ran into performance issues with the existing GDB remote
8 protocol that can be overcome when using a reliable communications layer.
9 Some packets improve performance, others allow for remote process launching
10 (if you have an OS), and others allow us to dynamically figure out what
11 registers a thread might have. Again with GDB, both sides pre-agree on how the
12 registers will look (how many, their register number,name and offsets). We
13 prefer to be able to dynamically determine what kind of architecture, OS and
14 vendor we are debugging, as well as how things are laid out when it comes to
15 the thread register contexts. Below are the details on the new packets we have
16 added above and beyond the standard GDB remote protocol packets.
18 //----------------------------------------------------------------------
22 // Try to enable no ACK mode to skip sending ACKs and NACKs.
24 // PRIORITY TO IMPLEMENT
25 // High. Any GDB remote server that can implement this should if the
26 // connection is reliable. This improves packet throughput and increases
27 // the performance of the connection.
28 //----------------------------------------------------------------------
29 Having to send an ACK/NACK after every packet slows things down a bit, so we
30 have a way to disable ACK packets to minimize the traffic for reliable
31 communication interfaces (like sockets). Below GDB or LLDB will send this
32 packet to try and disable ACKs. All lines that start with "send packet: " are
33 from GDB/LLDB, and all lines that start with "read packet: " are from the GDB
36 send packet: $QStartNoAckMode#b0
43 //----------------------------------------------------------------------
44 // "A" - launch args packet
47 // Launch a program using the supplied arguments
49 // PRIORITY TO IMPLEMENT
50 // Low. Only needed if the remote target wants to launch a target after
51 // making a connection to a GDB server that isn't already connected to
52 // an inferior process.
53 //----------------------------------------------------------------------
55 We have added support for the "set program arguments" packet where we can
56 start a connection to a remote server and then later supply the path to the
57 executable and the arguments to use when executing:
59 GDB remote docs for this:
61 set program arguments(reserved) Aarglen,argnum,arg,...
63 Where A is followed by the length in bytes of the hex encoded argument,
64 followed by an argument integer, and followed by the ASCII characters
65 converted into hex bytes foreach arg
67 send packet: $A98,0,2f566f6c756d65732f776f726b2f67636c6179746f6e2f446f63756d656e74732f7372632f6174746163682f612e6f7574#00
70 The above packet helps when you have remote debugging abilities where you
71 could launch a process on a remote host, this isn't needed for bare board
74 //----------------------------------------------------------------------
75 // "QEnvironment:NAME=VALUE"
78 // Setup the environment up for a new child process that will soon be
79 // launched using the "A" packet.
81 // NB: key/value pairs are sent as-is so gdb-remote protocol meta characters
82 // (e.g. '#' or '$') are not acceptable. If any non-printable or
83 // metacharacters are present in the strings, QEnvironmentHexEncoded
84 // should be used instead if it is available. If you don't want to
85 // scan the environment strings before sending, prefer
86 // the QEnvironmentHexEncoded packet over QEnvironment, if it is
89 // PRIORITY TO IMPLEMENT
90 // Low. Only needed if the remote target wants to launch a target after
91 // making a connection to a GDB server that isn't already connected to
92 // an inferior process.
93 //----------------------------------------------------------------------
95 Both GDB and LLDB support passing down environment variables. Is it ok to
96 respond with a "$#00" (unimplemented):
98 send packet: $QEnvironment:ACK_COLOR_FILENAME=bold yellow#00
101 This packet can be sent one or more times _prior_ to sending a "A" packet.
103 //----------------------------------------------------------------------
104 // "QEnvironmentHexEncoded:HEX-ENCODING(NAME=VALUE)"
107 // Setup the environment up for a new child process that will soon be
108 // launched using the "A" packet.
110 // The only difference between this packet and QEnvironment is that the
111 // environment key-value pair is ascii hex encoded for transmission.
112 // This allows values with gdb-remote metacharacters like '#' to be sent.
114 // PRIORITY TO IMPLEMENT
115 // Low. Only needed if the remote target wants to launch a target after
116 // making a connection to a GDB server that isn't already connected to
117 // an inferior process.
118 //----------------------------------------------------------------------
120 Both GDB and LLDB support passing down environment variables. Is it ok to
121 respond with a "$#00" (unimplemented):
123 send packet: $QEnvironment:41434b5f434f4c4f525f46494c454e414d453d626f6c642379656c6c6f77#00
126 This packet can be sent one or more times _prior_ to sending a "A" packet.
128 //----------------------------------------------------------------------
129 // "QEnableErrorStrings"
132 // This packet enables reporting of Error strings in remote packet
133 // replies from the server to client. If the server supports this
134 // feature, it should send an OK response. The client can expect the
135 // following error replies if this feature is enabled in the server ->
139 // where AAAAAAAAA will be a hex encoded ASCII string.
140 // XX is hex encoded byte number.
142 // It must be noted that even if the client has enabled reporting
143 // strings in error replies, it must not expect error strings to all
146 // PRIORITY TO IMPLEMENT
147 // Low. Only needed if the remote target wants to provide strings that
148 // are human readable along with an error code.
149 //----------------------------------------------------------------------
151 send packet: $QEnableErrorStrings
154 //----------------------------------------------------------------------
155 // "QSetSTDIN:<ascii-hex-path>"
156 // "QSetSTDOUT:<ascii-hex-path>"
157 // "QSetSTDERR:<ascii-hex-path>"
160 // Setup where STDIN, STDOUT, and STDERR go prior to sending an "A"
163 // PRIORITY TO IMPLEMENT
164 // Low. Only needed if the remote target wants to launch a target after
165 // making a connection to a GDB server that isn't already connected to
166 // an inferior process.
167 //----------------------------------------------------------------------
169 When launching a program through the GDB remote protocol with the "A" packet,
170 you might also want to specify where stdin/out/err go:
172 QSetSTDIN:<ascii-hex-path>
173 QSetSTDOUT:<ascii-hex-path>
174 QSetSTDERR:<ascii-hex-path>
176 These packets must be sent _prior_ to sending a "A" packet.
178 //----------------------------------------------------------------------
179 // "QSetWorkingDir:<ascii-hex-path>"
182 // Set the working directory prior to sending an "A" packet.
184 // PRIORITY TO IMPLEMENT
185 // Low. Only needed if the remote target wants to launch a target after
186 // making a connection to a GDB server that isn't already connected to
187 // an inferior process.
188 //----------------------------------------------------------------------
190 Or specify the working directory:
192 QSetWorkingDir:<ascii-hex-path>
194 This packet must be sent _prior_ to sending a "A" packet.
196 //----------------------------------------------------------------------
197 // "QSetDisableASLR:<bool>"
200 // Enable or disable ASLR on the next "A" packet.
202 // PRIORITY TO IMPLEMENT
203 // Low. Only needed if the remote target wants to launch a target after
204 // making a connection to a GDB server that isn't already connected to
205 // an inferior process and if the target supports disabling ASLR
206 // (Address space layout randomization).
207 //----------------------------------------------------------------------
209 Or control if ASLR is enabled/disabled:
211 send packet: QSetDisableASLR:1
214 send packet: QSetDisableASLR:0
217 This packet must be sent _prior_ to sending a "A" packet.
219 //----------------------------------------------------------------------
220 // QListThreadsInStopReply
223 // Enable the threads: and thread-pcs: data in the question-mark packet
224 // ("T packet") responses when the stub reports that a program has
225 // stopped executing.
227 // PRIORITY TO IMPLEMENT
228 // Performance. This is a performance benefit to lldb if the thread id's
229 // and thread pc values are provided to lldb in the T stop packet -- if
230 // they are not provided to lldb, lldb will likely need to send one to
231 // two packets per thread to fetch the data at every private stop.
232 //----------------------------------------------------------------------
234 send packet: QListThreadsInStopReply
237 //----------------------------------------------------------------------
238 // jLLDBTraceSupported
241 // Get the processor tracing type supported by the gdb-server for the current
242 // inferior. Responses might be different depending on the architecture and
243 // capabilities of the underlying OS.
248 // Tracing technology name, e.g. intel-pt, arm-coresight.
249 // "description": <string>,
250 // Description for this technology.
253 // If no tracing technology is supported for the inferior, or no process is
254 // running, then an error message is returned.
257 // This packet is used by Trace plug-ins (see lldb_private::Trace.h) to
258 // do live tracing. Specifically, the name of the plug-in should match the name
259 // of the tracing technology returned by this packet.
260 //----------------------------------------------------------------------
262 send packet: jLLDBTraceSupported
263 read packet: {"name":<name>, "description":<description>}/E<error code>;AAAAAAAAA
265 //----------------------------------------------------------------------
269 // Start tracing a process or its threads using a provided tracing technology.
270 // The input and output are specified as JSON objects. In case of success, an OK
271 // response is returned, or an error otherwise.
274 // This traces existing and future threads of the current process. An error is
275 // returned if the process is already being traced.
278 // This traces specific threads.
283 // Tracing technology name, e.g. intel-pt, arm-coresight.
285 // /* thread tracing only */
286 // "tids": [<decimal integer>],
287 // Individual threads to trace.
289 // ... other parameters specific to the provided tracing type
293 // - If "tids" is not provided, then the operation is "process tracing",
294 // otherwise it's "thread tracing".
295 // - Each tracing technology can have different levels of support for "thread
296 // tracing" and "process tracing".
299 // intel-pt supports both "thread tracing" and "process tracing".
301 // "Process tracing" is implemented by tracing each thread individually, but
302 // managed by the same "process trace" instance.
303 // Each actual thread trace, either from "process tracing" or "thread tracing",
304 // is stored in an in-memory circular buffer, which keeps the most recent data.
306 // Additional params in the input schema:
308 // "threadBufferSize": <decimal integer>,
309 // Trace buffer size per thread in bytes. It must be a power of 2
310 // greater than or equal to 4096 (2^12) bytes.
312 // "enableTsc": <boolean>,
313 // Whether to enable TSC timestamps or not. This is supported on
314 // all devices that support intel-pt. A TSC timestamp is generated along
315 // with PSB (synchronization) packets, whose frequency can be configured
316 // with the "psbPeriod" parameter.
318 // "psbPeriod"?: <Optional decimal integer>,
319 // This value defines the period in which PSB packets will be generated.
320 // A PSB packet is a synchronization packet that contains a TSC
321 // timestamp and the current absolute instruction pointer.
323 // This parameter can only be used if
325 // /sys/bus/event_source/devices/intel_pt/caps/psb_cyc
327 // is 1. Otherwise, the PSB period will be defined by the processor.
329 // If supported, valid values for this period can be found in
331 // /sys/bus/event_source/devices/intel_pt/caps/psb_periods
333 // which contains a hexadecimal number, whose bits represent valid
334 // values e.g. if bit 2 is set, then value 2 is valid.
336 // The psb_period value is converted to the approximate number of
337 // raw trace bytes between PSB packets as:
341 // e.g. value 3 means 16KiB between PSB packets. Defaults to
344 // /* process tracing only */
345 // "processBufferSizeLimit": <decimal integer>,
346 // Maximum total buffer size per process in bytes.
347 // This limit applies to the sum of the sizes of all trace buffers for
348 // the current process, excluding the ones started with "thread tracing".
350 // Whenever a thread is attempted to be traced due to "process tracing"
351 // and the limit would be reached, the process is stopped with a
352 // "tracing" reason along with a meaningful description, so that the
353 // user can retrace the process if needed.
357 // - Modifying the parameters of an existing trace is not supported. The user
358 // needs to stop the trace and start a new one.
359 // - If "process tracing" is attempted and there are individual threads
360 // already being traced with "thread tracing", these traces are left
361 // unaffected and the threads not traced twice.
362 // - If "thread tracing" is attempted on a thread already being traced with
363 // either "thread tracing" or "process tracing", it fails.
364 //----------------------------------------------------------------------
367 send packet: jLLDBTraceStart:{"type":<type>,...other params}]
368 read packet: OK/E<error code>;AAAAAAAAA
371 send packet: jLLDBTraceStart:{"type":<type>,"tids":<tids>,...other params}]
372 read packet: OK/E<error code>;AAAAAAAAA
374 //----------------------------------------------------------------------
378 // Stop tracing a process or its threads using a provided tracing technology.
379 // The input and output are specified as JSON objects. In case of success, an OK
380 // response is returned, or an error otherwise.
382 // PROCESS TRACE STOPPING
383 // Stopping a process trace stops the active traces initiated with
386 // THREAD TRACE STOPPING
387 // This is a best effort request, which tries to stop as many traces as
391 // The schema for the input is
395 // Tracing technology name, e.g. intel-pt, arm-coresight.
397 // /* thread trace stopping only */
398 // "tids": [<decimal integer>]
399 // Individual thread traces to stop.
403 // - If "tids" is not provided, then the operation is "process trace stopping".
406 // Stopping a specific thread trace started with "process tracing" is allowed.
407 //----------------------------------------------------------------------
409 Process trace stopping:
410 send packet: jLLDBTraceStop:{"type":<type>}]
411 read packet: OK/E<error code>;AAAAAAAAA
413 Thread trace stopping:
414 send packet: jLLDBTraceStop:{"type":<type>,"tids":<tids>}]
415 read packet: OK/E<error code>;AAAAAAAAA
417 //----------------------------------------------------------------------
418 // jLLDBTraceGetState
421 // Get the current state of the process and its threads being traced by
422 // a given trace technology. The response is a JSON object with custom
423 // information depending on the trace technology. In case of errors, an
424 // error message is returned.
429 // Tracing technology name, e.g. intel-pt, arm-coresight.
434 // "tracedThreads": [{
435 // "tid": <decimal integer>,
439 // Identifier for some binary data related to this thread to
440 // fetch with the jLLDBTraceGetBinaryData packet.
441 // "size": <decimal integer>,
442 // Size in bytes of this thread data.
446 // "processBinaryData": [
449 // Identifier for some binary data related to this process to
450 // fetch with the jLLDBTraceGetBinaryData packet.
451 // "size": <decimal integer>,
452 // Size in bytes of this thread data.
458 // - "traceThreads" includes all thread traced by both "process tracing" and
463 // Binary data kinds:
464 // - threadTraceBuffer: trace buffer for a thread.
465 // - cpuInfo: contents of the /proc/cpuinfo file.
466 //----------------------------------------------------------------------
468 send packet: jLLDBTraceGetState:{"type":<type>}]
469 read packet: {...object}/E<error code>;AAAAAAAAA
471 //----------------------------------------------------------------------
472 // jLLDBTraceGetBinaryData
475 // Get binary data given a trace technology and a data identifier.
476 // The input is specified as a JSON object and the response has the same format
477 // as the "binary memory read" (aka "x") packet. In case of failures, an error
478 // message is returned.
481 // The schema for the input is
485 // Tracing technology name, e.g. intel-pt, arm-coresight.
487 // Identifier for the data.
488 // "tid"?: <Optional decimal>,
489 // Tid in decimal if the data belongs to a thread.
490 // "offset": <decimal>,
491 // Offset of the data in bytes.
492 // "size": <decimal>,
493 // Number of bytes in to read starting from the offset.
498 // Binary data kinds:
499 // - threadTraceBuffer: trace buffer for a thread.
500 // - cpuInfo: contents of the /proc/cpuinfo file.
501 //----------------------------------------------------------------------
503 send packet: jLLDBTraceGetBinaryData:{"type":<type>,"kind":<query>,"tid":<tid>,"offset":<offset>,"size":<size>}]
504 read packet: <binary data>/E<error code>;AAAAAAAAA
506 //----------------------------------------------------------------------
507 // "qRegisterInfo<hex-reg-id>"
510 // Discover register information from the remote GDB server.
512 // PRIORITY TO IMPLEMENT
513 // High. Any target that can self describe its registers, should do so.
514 // This means if new registers are ever added to a remote target, they
515 // will get picked up automatically, and allows registers to change
516 // depending on the actual CPU type that is used.
518 // NB: As of summer 2015, lldb can get register information from the
519 // "qXfer:features:read:target.xml" FSF gdb standard register packet
520 // where the stub provides register definitions in an XML file.
521 // If qXfer:features:read:target.xml is supported, qRegisterInfo does
522 // not need to be implemented.
523 //----------------------------------------------------------------------
525 With LLDB, for register information, remote GDB servers can add
526 support for the "qRegisterInfoN" packet where "N" is a zero based
527 base16 register number that must start at zero and increase by one
528 for each register that is supported. The response is done in typical
529 GDB remote fashion where a series of "KEY:VALUE;" pairs are returned.
530 An example for the x86_64 registers is included below:
532 send packet: $qRegisterInfo0#00
533 read packet: $name:rax;bitsize:64;offset:0;encoding:uint;format:hex;set:General Purpose Registers;gcc:0;dwarf:0;#00
534 send packet: $qRegisterInfo1#00
535 read packet: $name:rbx;bitsize:64;offset:8;encoding:uint;format:hex;set:General Purpose Registers;gcc:3;dwarf:3;#00
536 send packet: $qRegisterInfo2#00
537 read packet: $name:rcx;bitsize:64;offset:16;encoding:uint;format:hex;set:General Purpose Registers;gcc:2;dwarf:2;#00
538 send packet: $qRegisterInfo3#00
539 read packet: $name:rdx;bitsize:64;offset:24;encoding:uint;format:hex;set:General Purpose Registers;gcc:1;dwarf:1;#00
540 send packet: $qRegisterInfo4#00
541 read packet: $name:rdi;bitsize:64;offset:32;encoding:uint;format:hex;set:General Purpose Registers;gcc:5;dwarf:5;#00
542 send packet: $qRegisterInfo5#00
543 read packet: $name:rsi;bitsize:64;offset:40;encoding:uint;format:hex;set:General Purpose Registers;gcc:4;dwarf:4;#00
544 send packet: $qRegisterInfo6#00
545 read packet: $name:rbp;alt-name:fp;bitsize:64;offset:48;encoding:uint;format:hex;set:General Purpose Registers;gcc:6;dwarf:6;generic:fp;#00
546 send packet: $qRegisterInfo7#00
547 read packet: $name:rsp;alt-name:sp;bitsize:64;offset:56;encoding:uint;format:hex;set:General Purpose Registers;gcc:7;dwarf:7;generic:sp;#00
548 send packet: $qRegisterInfo8#00
549 read packet: $name:r8;bitsize:64;offset:64;encoding:uint;format:hex;set:General Purpose Registers;gcc:8;dwarf:8;#00
550 send packet: $qRegisterInfo9#00
551 read packet: $name:r9;bitsize:64;offset:72;encoding:uint;format:hex;set:General Purpose Registers;gcc:9;dwarf:9;#00
552 send packet: $qRegisterInfoa#00
553 read packet: $name:r10;bitsize:64;offset:80;encoding:uint;format:hex;set:General Purpose Registers;gcc:10;dwarf:10;#00
554 send packet: $qRegisterInfob#00
555 read packet: $name:r11;bitsize:64;offset:88;encoding:uint;format:hex;set:General Purpose Registers;gcc:11;dwarf:11;#00
556 send packet: $qRegisterInfoc#00
557 read packet: $name:r12;bitsize:64;offset:96;encoding:uint;format:hex;set:General Purpose Registers;gcc:12;dwarf:12;#00
558 send packet: $qRegisterInfod#00
559 read packet: $name:r13;bitsize:64;offset:104;encoding:uint;format:hex;set:General Purpose Registers;gcc:13;dwarf:13;#00
560 send packet: $qRegisterInfoe#00
561 read packet: $name:r14;bitsize:64;offset:112;encoding:uint;format:hex;set:General Purpose Registers;gcc:14;dwarf:14;#00
562 send packet: $qRegisterInfof#00
563 read packet: $name:r15;bitsize:64;offset:120;encoding:uint;format:hex;set:General Purpose Registers;gcc:15;dwarf:15;#00
564 send packet: $qRegisterInfo10#00
565 read packet: $name:rip;alt-name:pc;bitsize:64;offset:128;encoding:uint;format:hex;set:General Purpose Registers;gcc:16;dwarf:16;generic:pc;#00
566 send packet: $qRegisterInfo11#00
567 read packet: $name:rflags;alt-name:flags;bitsize:64;offset:136;encoding:uint;format:hex;set:General Purpose Registers;#00
568 send packet: $qRegisterInfo12#00
569 read packet: $name:cs;bitsize:64;offset:144;encoding:uint;format:hex;set:General Purpose Registers;#00
570 send packet: $qRegisterInfo13#00
571 read packet: $name:fs;bitsize:64;offset:152;encoding:uint;format:hex;set:General Purpose Registers;#00
572 send packet: $qRegisterInfo14#00
573 read packet: $name:gs;bitsize:64;offset:160;encoding:uint;format:hex;set:General Purpose Registers;#00
574 send packet: $qRegisterInfo15#00
575 read packet: $name:fctrl;bitsize:16;offset:176;encoding:uint;format:hex;set:Floating Point Registers;#00
576 send packet: $qRegisterInfo16#00
577 read packet: $name:fstat;bitsize:16;offset:178;encoding:uint;format:hex;set:Floating Point Registers;#00
578 send packet: $qRegisterInfo17#00
579 read packet: $name:ftag;bitsize:8;offset:180;encoding:uint;format:hex;set:Floating Point Registers;#00
580 send packet: $qRegisterInfo18#00
581 read packet: $name:fop;bitsize:16;offset:182;encoding:uint;format:hex;set:Floating Point Registers;#00
582 send packet: $qRegisterInfo19#00
583 read packet: $name:fioff;bitsize:32;offset:184;encoding:uint;format:hex;set:Floating Point Registers;#00
584 send packet: $qRegisterInfo1a#00
585 read packet: $name:fiseg;bitsize:16;offset:188;encoding:uint;format:hex;set:Floating Point Registers;#00
586 send packet: $qRegisterInfo1b#00
587 read packet: $name:fooff;bitsize:32;offset:192;encoding:uint;format:hex;set:Floating Point Registers;#00
588 send packet: $qRegisterInfo1c#00
589 read packet: $name:foseg;bitsize:16;offset:196;encoding:uint;format:hex;set:Floating Point Registers;#00
590 send packet: $qRegisterInfo1d#00
591 read packet: $name:mxcsr;bitsize:32;offset:200;encoding:uint;format:hex;set:Floating Point Registers;#00
592 send packet: $qRegisterInfo1e#00
593 read packet: $name:mxcsrmask;bitsize:32;offset:204;encoding:uint;format:hex;set:Floating Point Registers;#00
594 send packet: $qRegisterInfo1f#00
595 read packet: $name:stmm0;bitsize:80;offset:208;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:33;dwarf:33;#00
596 send packet: $qRegisterInfo20#00
597 read packet: $name:stmm1;bitsize:80;offset:224;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:34;dwarf:34;#00
598 send packet: $qRegisterInfo21#00
599 read packet: $name:stmm2;bitsize:80;offset:240;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:35;dwarf:35;#00
600 send packet: $qRegisterInfo22#00
601 read packet: $name:stmm3;bitsize:80;offset:256;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:36;dwarf:36;#00
602 send packet: $qRegisterInfo23#00
603 read packet: $name:stmm4;bitsize:80;offset:272;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:37;dwarf:37;#00
604 send packet: $qRegisterInfo24#00
605 read packet: $name:stmm5;bitsize:80;offset:288;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:38;dwarf:38;#00
606 send packet: $qRegisterInfo25#00
607 read packet: $name:stmm6;bitsize:80;offset:304;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:39;dwarf:39;#00
608 send packet: $qRegisterInfo26#00
609 read packet: $name:stmm7;bitsize:80;offset:320;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:40;dwarf:40;#00
610 send packet: $qRegisterInfo27#00
611 read packet: $name:xmm0;bitsize:128;offset:336;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:17;dwarf:17;#00
612 send packet: $qRegisterInfo28#00
613 read packet: $name:xmm1;bitsize:128;offset:352;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:18;dwarf:18;#00
614 send packet: $qRegisterInfo29#00
615 read packet: $name:xmm2;bitsize:128;offset:368;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:19;dwarf:19;#00
616 send packet: $qRegisterInfo2a#00
617 read packet: $name:xmm3;bitsize:128;offset:384;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:20;dwarf:20;#00
618 send packet: $qRegisterInfo2b#00
619 read packet: $name:xmm4;bitsize:128;offset:400;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:21;dwarf:21;#00
620 send packet: $qRegisterInfo2c#00
621 read packet: $name:xmm5;bitsize:128;offset:416;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:22;dwarf:22;#00
622 send packet: $qRegisterInfo2d#00
623 read packet: $name:xmm6;bitsize:128;offset:432;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:23;dwarf:23;#00
624 send packet: $qRegisterInfo2e#00
625 read packet: $name:xmm7;bitsize:128;offset:448;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:24;dwarf:24;#00
626 send packet: $qRegisterInfo2f#00
627 read packet: $name:xmm8;bitsize:128;offset:464;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:25;dwarf:25;#00
628 send packet: $qRegisterInfo30#00
629 read packet: $name:xmm9;bitsize:128;offset:480;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:26;dwarf:26;#00
630 send packet: $qRegisterInfo31#00
631 read packet: $name:xmm10;bitsize:128;offset:496;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:27;dwarf:27;#00
632 send packet: $qRegisterInfo32#00
633 read packet: $name:xmm11;bitsize:128;offset:512;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:28;dwarf:28;#00
634 send packet: $qRegisterInfo33#00
635 read packet: $name:xmm12;bitsize:128;offset:528;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:29;dwarf:29;#00
636 send packet: $qRegisterInfo34#00
637 read packet: $name:xmm13;bitsize:128;offset:544;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:30;dwarf:30;#00
638 send packet: $qRegisterInfo35#00
639 read packet: $name:xmm14;bitsize:128;offset:560;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:31;dwarf:31;#00
640 send packet: $qRegisterInfo36#00
641 read packet: $name:xmm15;bitsize:128;offset:576;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:32;dwarf:32;#00
642 send packet: $qRegisterInfo37#00
643 read packet: $name:trapno;bitsize:32;offset:696;encoding:uint;format:hex;set:Exception State Registers;#00
644 send packet: $qRegisterInfo38#00
645 read packet: $name:err;bitsize:32;offset:700;encoding:uint;format:hex;set:Exception State Registers;#00
646 send packet: $qRegisterInfo39#00
647 read packet: $name:faultvaddr;bitsize:64;offset:704;encoding:uint;format:hex;set:Exception State Registers;#00
648 send packet: $qRegisterInfo3a#00
651 As we see above we keep making subsequent calls to the remote server to
652 discover all registers by increasing the number appended to qRegisterInfo and
653 we get a response back that is a series of "key=value;" strings.
655 The offset: fields should not leave a gap anywhere in the g/G packet -- the
656 register values should be appended one after another. For instance, if the
657 register context for a thread looks like
660 uint32_t gpr1; // offset 0
661 uint32_t gpr2; // offset 4
662 uint32_t gpr3; // offset 8
663 uint64_t fp1; // offset 16
666 You may end up with a 4-byte gap between gpr3 and fp1 on architectures
667 that align values like this. The correct offset: value for fp1 is 12 -
668 in the g/G packet fp1 will immediately follow gpr3, even though the
669 in-memory thread structure has an empty 4 bytes for alignment between
672 The keys and values are detailed below:
675 ========== ================================================================
676 name The primary register name as a string ("rbp" for example)
678 alt-name An alternate name for a register as a string ("fp" for example for
681 bitsize Size in bits of a register (32, 64, etc). Base 10.
683 offset The offset within the "g" and "G" packet of the register data for
684 this register. This is the byte offset once the data has been
685 transformed into binary, not the character offset into the g/G
688 encoding The encoding type of the register which must be one of:
690 uint (unsigned integer)
691 sint (signed integer)
692 ieee754 (IEEE 754 float)
693 vector (vector register)
695 format The preferred format for display of this register. The value must
711 set The register set name as a string that this register belongs to.
713 gcc The GCC compiler registers number for this register (used for
714 EH frame and other compiler information that is encoded in the
715 executable files). The supplied number will be decoded like a
716 string passed to strtoul() with a base of zero, so the number
717 can be decimal, or hex if it is prefixed with "0x".
719 NOTE: If the compiler doesn't have a register number for this
720 register, this key/value pair should be omitted.
722 dwarf The DWARF register number for this register that is used for this
723 register in the debug information. The supplied number will be decoded
724 like a string passed to strtoul() with a base of zero, so the number
725 can be decimal, or hex if it is prefixed with "0x".
727 NOTE: If the compiler doesn't have a register number for this
728 register, this key/value pair should be omitted.
730 generic If the register is a generic register that most CPUs have, classify
731 it correctly so the debugger knows. Valid values are one of:
732 pc (a program counter register. for example "name=eip;" (i386),
733 "name=rip;" (x86_64), "name=r15;" (32 bit arm) would
734 include a "generic=pc;" key value pair)
735 sp (a stack pointer register. for example "name=esp;" (i386),
736 "name=rsp;" (x86_64), "name=r13;" (32 bit arm) would
737 include a "generic=sp;" key value pair)
738 fp (a frame pointer register. for example "name=ebp;" (i386),
739 "name=rbp;" (x86_64), "name=r7;" (32 bit arm with macosx
740 ABI) would include a "generic=fp;" key value pair)
741 ra (a return address register. for example "name=lr;" (32 bit ARM)
742 would include a "generic=ra;" key value pair)
743 fp (a CPU flags register. for example "name=eflags;" (i386),
744 "name=rflags;" (x86_64), "name=cpsr;" (32 bit ARM)
745 would include a "generic=flags;" key value pair)
746 arg1 - arg8 (specified for registers that contain function
747 arguments when the argument fits into a register)
750 The value for this key is a comma separated list of raw hex (optional
751 leading "0x") register numbers.
753 This specifies that this register is contained in other concrete
754 register values. For example "eax" is in the lower 32 bits of the
755 "rax" register value for x86_64, so "eax" could specify that it is
756 contained in "rax" by specifying the register number for "rax" (whose
757 register number is 0x00)
761 If a register is comprised of one or more registers, like "d0" is ARM
762 which is a 64 bit register, it might be made up of "s0" and "s1". If
763 the register number for "s0" is 0x20, and the register number of "s1"
764 is "0x21", the "container-regs" key/value pair would be:
766 "container-regs:20,21;"
768 This is handy for defining what GDB used to call "pseudo" registers.
769 These registers are never requested by LLDB via the register read
770 or write packets, the container registers will be requested on behalf
774 The value for this key is a comma separated list of raw hex (optional
775 leading "0x") register numbers.
777 This specifies which register values should be invalidated when this
778 register is modified. For example if modifying "eax" would cause "rax",
779 "eax", "ax", "ah", and "al" to be modified where rax is 0x0, eax is 0x15,
780 ax is 0x25, ah is 0x35, and al is 0x39, the "invalidate-regs" key/value
783 "invalidate-regs:0,15,25,35,39;"
785 If there is a single register that gets invalidated, then omit the comma
786 and just list a single register:
790 This is handy when modifying a specific register can cause other
791 register values to change. For example, when debugging an ARM target,
792 modifying the CPSR register can cause the r8 - r14 and cpsr value to
793 change depending on if the mode has changed.
795 //----------------------------------------------------------------------
799 // Run a command in a shell on the connected remote machine.
801 // PRIORITY TO IMPLEMENT
802 // High. This command allows LLDB clients to run arbitrary shell
803 // commands on a remote host.
805 /----------------------------------------------------------------------
807 The request consists of the command to be executed encoded in ASCII characters
808 converted into hex bytes.
810 The response to this packet consists of the letter F followed by the return code,
811 followed by the signal number (or 0 if no signal was delivered), and escaped bytes
812 of captured program output.
814 Below is an example communication from a client sending an "ls -la" command:
816 send packet: $qPlatform_shell:6c73202d6c61,00000002#ec
817 read packet: $F,00000000,00000000,total 4736
818 drwxrwxr-x 16 username groupname 4096 Aug 15 21:36 .
819 drwxr-xr-x 17 username groupname 4096 Aug 10 16:39 ..
820 -rw-rw-r-- 1 username groupname 73875 Aug 12 16:46 notes.txt
821 drwxrwxr-x 5 username groupname 4096 Aug 15 21:36 source.cpp
822 -rw-r--r-- 1 username groupname 2792 Aug 12 16:46 a.out
823 -rw-r--r-- 1 username groupname 3190 Aug 12 16:46 Makefile
825 //----------------------------------------------------------------------
829 // Creates a new directory on the connected remote machine.
831 // PRIORITY TO IMPLEMENT
832 // Low. This command allows LLDB clients to create new directories on
835 /----------------------------------------------------------------------
838 qPlatform_mkdir:<hex-file-mode>,<ascii-hex-path>
842 mkdir called successfully and returned with the given return code
846 //----------------------------------------------------------------------
850 // Change the permissions of a file on the connected remote machine.
852 // PRIORITY TO IMPLEMENT
853 // Low. This command allows LLDB clients to change the permissions of
854 // a file on the remote host.
856 /----------------------------------------------------------------------
859 qPlatform_chmod:<hex-file-mode>,<ascii-hex-path>
863 chmod called successfully and returned with the given return code
867 //----------------------------------------------------------------------
871 // Get information about the host we are remotely connected to.
873 // PRIORITY TO IMPLEMENT
874 // High. This packet is usually very easy to implement and can help
875 // LLDB select the correct plug-ins for the job based on the target
876 // triple information that is supplied.
877 //----------------------------------------------------------------------
879 LLDB supports a host info call that gets all sorts of details of the system
880 that is being debugged:
882 send packet: $qHostInfo#00
883 read packet: $cputype:16777223;cpusubtype:3;ostype:darwin;vendor:apple;endian:little;ptrsize:8;#00
885 Key value pairs are one of:
887 cputype: is a number that is the mach-o CPU type that is being debugged (base 10)
888 cpusubtype: is a number that is the mach-o CPU subtype type that is being debugged (base 10)
889 triple: a string for the target triple (x86_64-apple-macosx) that can be used to specify arch + vendor + os in one entry
890 vendor: a string for the vendor (apple), not needed if "triple" is specified
891 ostype: a string for the OS being debugged (macosx, linux, freebsd, ios, watchos), not needed if "triple" is specified
892 endian: is one of "little", "big", or "pdp"
893 ptrsize: an unsigned number that represents how big pointers are in bytes on the debug target
894 hostname: the hostname of the host that is running the GDB server if available
895 os_build: a string for the OS build for the remote host as a string value
896 os_kernel: a string describing the kernel version
897 os_version: a version string that represents the current OS version (10.8.2)
898 watchpoint_exceptions_received: one of "before" or "after" to specify if a watchpoint is triggered before or after the pc when it stops
899 default_packet_timeout: an unsigned number that specifies the default timeout in seconds
900 distribution_id: optional. For linux, specifies distribution id (e.g. ubuntu, fedora, etc.)
901 osmajor: optional, specifies the major version number of the OS (e.g. for macOS 10.12.2, it would be 10)
902 osminor: optional, specifies the minor version number of the OS (e.g. for macOS 10.12.2, it would be 12)
903 ospatch: optional, specifies the patch level number of the OS (e.g. for macOS 10.12.2, it would be 2)
904 vm-page-size: optional, specifies the target system VM page size, base 10.
905 Needed for the "dirty-pages:" list in the qMemoryRegionInfo
906 packet, where a list of dirty pages is sent from the remote
907 stub. This page size tells lldb how large each dirty page is.
908 addressing_bits: optional, specifies how many bits in addresses are
909 significant for addressing, base 10. If bits 38..0
910 in a 64-bit pointer are significant for addressing,
911 then the value is 39. This is needed on e.g. AArch64
912 v8.3 ABIs that use pointer authentication, so lldb
913 knows which bits to clear/set to get the actual
916 //----------------------------------------------------------------------
917 // "qGDBServerVersion"
920 // Get version information about this implementation of the gdb-remote
923 // PRIORITY TO IMPLEMENT
924 // High. This packet is usually very easy to implement and can help
925 // LLDB to work around bugs in a server's implementation when they
927 //----------------------------------------------------------------------
929 The goal of this packet is to provide enough information about an
930 implementation of the gdb-remote-protocol server that lldb can
931 work around implementation problems that are discovered after the
932 version has been released/deployed. The name and version number
933 should be sufficiently unique that lldb can unambiguously identify
934 the origin of the program (for instance, debugserver from lldb) and
935 the version/submission number/patch level of the program - whatever
936 is appropriate for your server implementation.
938 The packet follows the key-value pair model, semicolon separated.
940 send packet: $qGDBServerVersion#00
941 read packet: $name:debugserver;version:310.2;#00
943 Other clients may find other key-value pairs to be useful for identifying
944 a gdb stub. Patch level, release name, build number may all be keys that
945 better describe your implementation's version.
948 name : the name of your remote server - "debugserver" is the lldb standard
951 version : identifies the version number of this server
953 patch_level : the patch level of this server
955 release_name : the name of this release, if your project uses names
957 build_number : if you use a build system with increasing build numbers,
958 this may be the right key name for your server
960 major_version : major version number
961 minor_version : minor version number
963 //----------------------------------------------------------------------
967 // Get information about the process we are currently debugging.
969 // PRIORITY TO IMPLEMENT
970 // Medium. On systems which can launch multiple different architecture processes,
971 // the qHostInfo may not disambiguate sufficiently to know what kind of
972 // process is being debugged.
973 // e.g. on a 64-bit x86 Mac system both 32-bit and 64-bit user processes are possible,
974 // and with Mach-O universal files, the executable file may contain both 32- and
975 // 64-bit slices so it may be impossible to know until you're attached to a real
976 // process to know what you're working with.
978 // All numeric fields return base-16 numbers without any "0x" prefix.
979 //----------------------------------------------------------------------
983 send packet: $qProcessInfo#00
984 read packet: $pid:42a8;parent-pid:42bf;real-uid:ecf;real-gid:b;effective-uid:ecf;effective-gid:b;cputype:7;cpusubtype:3;ostype:macosx;vendor:apple;endian:little;ptrsize:4;#00
988 send packet: $qProcessInfo#00
989 read packet: $pid:d22c;parent-pid:d34d;real-uid:ecf;real-gid:b;effective-uid:ecf;effective-gid:b;cputype:1000007;cpusubtype:3;ostype:macosx;vendor:apple;endian:little;ptrsize:8;#00
991 Key value pairs include:
994 parent-pid: the process of the parent process (often debugserver will become the parent when attaching)
995 real-uid: the real user id of the process
996 real-gid: the real group id of the process
997 effective-uid: the effective user id of the process
998 effective-gid: the effective group id of the process
999 cputype: the Mach-O CPU type of the process (base 16)
1000 cpusubtype: the Mach-O CPU subtype of the process (base 16)
1001 ostype: is a string the represents the OS being debugged (darwin, linux, freebsd)
1002 vendor: is a string that represents the vendor (apple)
1003 endian: is one of "little", "big", or "pdp"
1004 ptrsize: is a number that represents how big pointers are in bytes
1006 main-binary-uuid: is the UUID of a firmware type binary that the gdb stub knows about
1007 main-binary-address: is the load address of the firmware type binary
1008 main-binary-slide: is the slide of the firmware type binary, if address isn't known
1010 //----------------------------------------------------------------------
1014 // Get an address where the dynamic linker stores information about
1015 // where shared libraries are loaded.
1017 // PRIORITY TO IMPLEMENT
1018 // High if you have a dynamic loader plug-in in LLDB for your target
1019 // triple (see the "qHostInfo" packet) that can use this information.
1020 // Many times address load randomization can make it hard to detect
1021 // where the dynamic loader binary and data structures are located and
1022 // some platforms know, or can find out where this information is.
1024 // Low if you have a debug target where all object and symbol files
1025 // contain static load addresses.
1026 //----------------------------------------------------------------------
1028 LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to each
1029 debugger as to where to find the dynamic loader information. For darwin
1030 binaries that run in user land this is the address of the "all_image_infos"
1031 structure in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO
1032 call. The result is returned as big endian hex bytes that are the address
1035 send packet: $qShlibInfoAddr#00
1036 read packet: $7fff5fc40040#00
1040 //----------------------------------------------------------------------
1041 // "qThreadStopInfo<tid>"
1044 // Get information about why a thread, whose ID is "<tid>", is stopped.
1046 // PRIORITY TO IMPLEMENT
1047 // High if you need to support multi-threaded or multi-core debugging.
1048 // Many times one thread will hit a breakpoint and while the debugger
1049 // is in the process of suspending the other threads, other threads
1050 // will also hit a breakpoint. This packet allows LLDB to know why all
1051 // threads (live system debug) / cores (JTAG) in your program have
1052 // stopped and allows LLDB to display and control your program
1054 //----------------------------------------------------------------------
1056 LLDB tries to use the "qThreadStopInfo" packet which is formatted as
1057 "qThreadStopInfo%x" where %x is the hex thread ID. This requests information
1058 about why a thread is stopped. The response is the same as the stop reply
1059 packets and tells us what happened to the other threads. The standard GDB
1060 remote packets love to think that there is only _one_ reason that _one_ thread
1061 stops at a time. This allows us to see why all threads stopped and allows us
1062 to implement better multi-threaded debugging support.
1064 //----------------------------------------------------------------------
1065 // "QThreadSuffixSupported"
1068 // Try to enable thread suffix support for the 'g', 'G', 'p', and 'P'
1071 // PRIORITY TO IMPLEMENT
1072 // High. Adding a thread suffix allows us to read and write registers
1073 // more efficiently and stops us from having to select a thread with
1074 // one packet and then read registers with a second packet. It also
1075 // makes sure that no errors can occur where the debugger thinks it
1076 // already has a thread selected (see the "Hg" packet from the standard
1077 // GDB remote protocol documentation) yet the remote GDB server actually
1078 // has another thread selected.
1079 //----------------------------------------------------------------------
1081 When reading thread registers, you currently need to set the current
1082 thread, then read the registers. This is kind of cumbersome, so we added the
1083 ability to query if the remote GDB server supports adding a "thread:<tid>;"
1084 suffix to all packets that request information for a thread. To test if the
1085 remote GDB server supports this feature:
1087 send packet: $QThreadSuffixSupported#00
1090 If "OK" is returned, then the 'g', 'G', 'p' and 'P' packets can accept a
1091 thread suffix. So to send a 'g' packet (read all register values):
1093 send packet: $g;thread:<tid>;#00
1096 send packet: $G;thread:<tid>;#00
1099 send packet: $p1a;thread:<tid>;#00
1102 send packet: $P1a=1234abcd;thread:<tid>;#00
1106 otherwise, without this you would need to always send two packets:
1108 send packet: $Hg<tid>#00
1113 We also added support for allocating and deallocating memory. We use this to
1114 allocate memory so we can run JITed code.
1116 //----------------------------------------------------------------------
1117 // "_M<size>,<permissions>"
1120 // Allocate memory on the remote target with the specified size and
1123 // PRIORITY TO IMPLEMENT
1124 // High if you want LLDB to be able to JIT code and run that code. JIT
1125 // code also needs data which is also allocated and tracked.
1127 // Low if you don't support running JIT'ed code.
1128 //----------------------------------------------------------------------
1130 The allocate memory packet starts with "_M<size>,<permissions>". It returns a
1131 raw big endian address value, or "" for unimplemented, or "EXX" for an error
1132 code. The packet is formatted as:
1136 packet_len = ::snprintf (
1141 permissions & lldb::ePermissionsReadable ? "r" : "",
1142 permissions & lldb::ePermissionsWritable ? "w" : "",
1143 permissions & lldb::ePermissionsExecutable ? "x" : "");
1145 You request a size and give the permissions. This packet does NOT need to be
1146 implemented if you don't want to support running JITed code. The return value
1147 is just the address of the newly allocated memory as raw big endian hex bytes.
1149 //----------------------------------------------------------------------
1153 // Deallocate memory that was previously allocated using an allocate
1156 // PRIORITY TO IMPLEMENT
1157 // High if you want LLDB to be able to JIT code and run that code. JIT
1158 // code also needs data which is also allocated and tracked.
1160 // Low if you don't support running JIT'ed code.
1161 //----------------------------------------------------------------------
1163 The deallocate memory packet is "_m<addr>" where you pass in the address you
1164 got back from a previous call to the allocate memory packet. It returns "OK"
1165 if the memory was successfully deallocated, or "EXX" for an error, or "" if
1168 //----------------------------------------------------------------------
1169 // "qMemoryRegionInfo:<addr>"
1172 // Get information about the address range that contains "<addr>"
1174 // PRIORITY TO IMPLEMENT
1175 // Medium. This is nice to have, but it isn't necessary. It helps LLDB
1176 // do stack unwinding when we branch into memory that isn't executable.
1177 // If we can detect that the code we are stopped in isn't executable,
1178 // then we can recover registers for stack frames above the current
1179 // frame. Otherwise we must assume we are in some JIT'ed code (not JIT
1180 // code that LLDB has made) and assume that no registers are available
1181 // in higher stack frames.
1182 //----------------------------------------------------------------------
1184 We added a way to get information for a memory region. The packet is:
1186 qMemoryRegionInfo:<addr>
1188 Where <addr> is a big endian hex address. The response is returned in a series
1189 of tuples like the data returned in a stop reply packet. The currently valid
1190 tuples to return are:
1192 start:<start-addr>; // <start-addr> is a big endian hex address that is
1193 // the start address of the range that contains <addr>
1195 size:<size>; // <size> is a big endian hex byte size of the address
1196 // of the range that contains <addr>
1198 permissions:<permissions>; // <permissions> is a string that contains one
1199 // or more of the characters from "rwx"
1201 name:<name>; // <name> is a hex encoded string that contains the name of
1202 // the memory region mapped at the given address. In case of
1203 // regions backed by a file it have to be the absolute path of
1204 // the file while for anonymous regions it have to be the name
1205 // associated to the region if that is available.
1207 flags:<flags-string>; // where <flags-string> is a space separated string
1208 // of flag names. Currently the only supported flag
1209 // is "mt" for AArch64 memory tagging. lldb will
1210 // ignore any other flags in this field.
1212 type:[<type>][,<type>]; // memory types that apply to this region, e.g.
1213 // "stack" for stack memory.
1215 error:<ascii-byte-error-string>; // where <ascii-byte-error-string> is
1216 // a hex encoded string value that
1217 // contains an error string
1219 dirty-pages:[<hexaddr>][,<hexaddr]; // A list of memory pages within this
1220 // region that are "dirty" -- they have been modified.
1221 // Page addresses are in base16. The size of a page can
1222 // be found from the qHostInfo's page-size key-value.
1224 // If the stub supports identifying dirty pages within a
1225 // memory region, this key should always be present for all
1226 // qMemoryRegionInfo replies. This key with no pages
1227 // listed ("dirty-pages:;") indicates no dirty pages in
1228 // this memory region. The *absence* of this key means
1229 // that this stub cannot determine dirty pages.
1231 If the address requested is not in a mapped region (e.g. we've jumped through
1232 a NULL pointer and are at 0x0) currently lldb expects to get back the size
1233 of the unmapped region -- that is, the distance to the next valid region.
1234 For instance, with a macOS process which has nothing mapped in the first
1235 4GB of its address space, if we're asking about address 0x2,
1238 start:2;size:fffffffe;
1240 The lack of 'permissions:' indicates that none of read/write/execute are valid
1243 //----------------------------------------------------------------------
1244 // "x" - Binary memory read
1246 // Like the 'm' (read) and 'M' (write) packets, this is a partner to the
1247 // 'X' (write binary data) packet, 'x'.
1249 // It is called like
1253 // where both ADDRESS and LENGTH are big-endian base 16 values.
1255 // To test if this packet is available, send a addr/len of 0:
1259 // and you will get an "OK" response.
1261 // The reply will be the data requested in 8-bit binary data format.
1262 // The standard quoting is applied to the payload -- characters
1264 // will all be escaped with '}' (0x7d) character and then XOR'ed with 0x20.
1266 // A typical use to read 512 bytes at 0x1000 would look like
1270 // The "0x" prefixes are optional - like most of the gdb-remote packets,
1271 // omitting them will work fine; these numbers are always base 16.
1273 // The length of the payload is not provided. A reliable, 8-bit clean,
1274 // transport layer is assumed.
1275 //----------------------------------------------------------------------
1277 //----------------------------------------------------------------------
1278 // Detach and stay stopped:
1280 // We extended the "D" packet to specify that the monitor should keep the
1281 // target suspended on detach. The normal behavior is to resume execution
1282 // on detach. We will send:
1284 // qSupportsDetachAndStayStopped:
1286 // to query whether the monitor supports the extended detach, and if it does,
1287 // when we want the monitor to detach but not resume the target, we will
1292 // In any case, if we want the normal detach behavior we will just send:
1295 //----------------------------------------------------------------------
1297 //----------------------------------------------------------------------
1298 // QSaveRegisterState
1299 // QSaveRegisterState;thread:XXXX;
1302 // The QSaveRegisterState packet tells the remote debugserver to save
1303 // all registers and return a non-zero unique integer ID that
1304 // represents these save registers. If thread suffixes are enabled the
1305 // second form of this packet is used, otherwise the first form is
1306 // used. This packet is called prior to executing an expression, so
1307 // the remote GDB server should do anything it needs to in order to
1308 // ensure the registers that are saved are correct. On macOS this
1309 // involves calling "thread_abort_safely(mach_port_t thread)" to
1310 // ensure we get the correct registers for a thread in case it is
1311 // currently having code run on its behalf in the kernel.
1314 // unsigned - The save_id result is a non-zero unsigned integer value
1315 // that can be passed back to the GDB server using a
1316 // QRestoreRegisterState packet to restore the registers
1318 // "EXX" - or an error code in the form of EXX where XX is a
1321 // PRIORITY TO IMPLEMENT
1322 // Low, this is mostly a convenience packet to avoid having to send all
1323 // registers via a g packet. It should only be implemented if support
1324 // for the QRestoreRegisterState is added.
1325 //----------------------------------------------------------------------
1327 //----------------------------------------------------------------------
1328 // QRestoreRegisterState:<save_id>
1329 // QRestoreRegisterState:<save_id>;thread:XXXX;
1332 // The QRestoreRegisterState packet tells the remote debugserver to
1333 // restore all registers using the "save_id" which is an unsigned
1334 // integer that was returned from a previous call to
1335 // QSaveRegisterState. The restoration process can only be done once
1336 // as the data backing the register state will be freed upon the
1337 // completion of the QRestoreRegisterState command.
1339 // If thread suffixes are enabled the second form of this packet is
1340 // used, otherwise the first form is used.
1343 // "OK" - if all registers were successfully restored
1344 // "EXX" - for any errors
1346 // PRIORITY TO IMPLEMENT
1347 // Low, this is mostly a convenience packet to avoid having to send all
1348 // registers via a g packet. It should only be implemented if support
1349 // for the QSaveRegisterState is added.
1350 //----------------------------------------------------------------------
1352 //----------------------------------------------------------------------
1353 // qFileLoadAddress:<file_path>
1356 // Get the load address of a memory mapped file.
1357 // The load address is defined as the address of the first memory
1358 // region what contains data mapped from the specified file.
1361 // <unsigned-hex64> - Load address of the file in big endian encoding
1362 // "E01" - the requested file isn't loaded
1363 // "EXX" - for any other errors
1365 // PRIORITY TO IMPLEMENT
1366 // Low, required if dynamic linker don't fill in the load address of
1367 // some object file in the rendezvous data structure.
1368 //----------------------------------------------------------------------
1370 //----------------------------------------------------------------------
1371 // qModuleInfo:<module_path>;<arch triple>
1374 // Get information for a module by given module path and architecture.
1377 // "(uuid|md5):...;triple:...;file_offset:...;file_size...;"
1378 // "EXX" - for any errors
1380 // PRIORITY TO IMPLEMENT
1381 // Optional, required if dynamic loader cannot fetch module's information like
1382 // UUID directly from inferior's memory.
1383 //----------------------------------------------------------------------
1385 //----------------------------------------------------------------------
1386 // jModulesInfo:[{"file":"...",triple:"..."}, ...]
1389 // Get information for a list of modules by given module path and
1393 // A JSON array of dictionaries containing the following keys: uuid,
1394 // triple, file_path, file_offset, file_size. The meaning of the fields
1395 // is the same as in the qModuleInfo packet. The server signals the
1396 // failure to retrieve the module info for a file by ommiting the
1397 // corresponding array entry from the response. The server may also
1398 // include entries the client did not ask for, if it has reason to
1399 // the modules will be interesting to the client.
1401 // PRIORITY TO IMPLEMENT
1402 // Optional. If not implemented, qModuleInfo packet will be used, which
1403 // may be slower if the target contains a large number of modules and
1404 // the communication link has a non-negligible latency.
1405 //----------------------------------------------------------------------
1407 //----------------------------------------------------------------------
1408 // Stop reply packet extensions
1411 // This section describes some of the additional information you can
1412 // specify in stop reply packets that help LLDB to know more detailed
1413 // information about your threads.
1416 // Standard GDB remote stop reply packets are reply packets sent in
1417 // response to a packet that made the program run. They come in the
1421 // "S" means signal and "AA" is a hex signal number that describes why
1422 // the thread or stopped. It doesn't specify which thread, so the "T"
1423 // packet is recommended to use instead of the "S" packet.
1425 // "TAAkey1:value1;key2:value2;..."
1426 // "T" means a thread stopped due to a unix signal where "AA" is a hex
1427 // signal number that describes why the program stopped. This is
1428 // followed by a series of key/value pairs:
1429 // - If key is a hex number, it is a register number and value is
1430 // the hex value of the register in debuggee endian byte order.
1431 // - If key == "thread", then the value is the big endian hex
1432 // thread-id of the stopped thread.
1433 // - If key == "core", then value is a hex number of the core on
1434 // which the stop was detected.
1435 // - If key == "watch" or key == "rwatch" or key == "awatch", then
1436 // value is the data address in big endian hex
1437 // - If key == "library", then value is ignore and "qXfer:libraries:read"
1438 // packets should be used to detect any newly loaded shared libraries
1441 // "W" means the process exited and "AA" is the exit status.
1444 // "X" means the process exited and "AA" is signal that caused the program
1447 // "O<ascii-hex-string>"
1448 // "O" means STDOUT has data that was written to its console and is
1449 // being delivered to the debugger. This packet happens asynchronously
1450 // and the debugger is expected to continue to wait for another stop reply
1455 // We have extended the "T" packet to be able to also understand the
1456 // following keys and values:
1458 // KEY VALUE DESCRIPTION
1459 // =========== ======== ================================================
1460 // "metype" unsigned mach exception type (the value of the EXC_XXX enumerations)
1461 // as an unsigned integer. For targets with mach
1464 // "mecount" unsigned mach exception data count as an unsigned integer
1465 // For targets with mach kernels only.
1467 // "medata" unsigned There should be "mecount" of these and it is the data
1468 // that goes along with a mach exception (as an unsigned
1469 // integer). For targets with mach kernels only.
1471 // "name" string The name of the thread as a plain string. The string
1472 // must not contain an special packet characters or
1473 // contain a ':' or a ';'. Use "hexname" if the thread
1474 // name has special characters.
1476 // "hexname" ascii-hex An ASCII hex string that contains the name of the thread
1478 // "qaddr" hex Big endian hex value that contains the libdispatch
1479 // queue address for the queue of the thread.
1481 // "reason" enum The enumeration must be one of:
1482 // "trace" the program stopped after a single instruction
1483 // was executed on a core. Usually done when single
1484 // stepping past a breakpoint
1485 // "breakpoint" a breakpoint set using a 'z' packet was hit.
1486 // "trap" stopped due to user interruption
1487 // "signal" stopped due to an actual unix signal, not
1488 // just the debugger using a unix signal to keep
1489 // the GDB remote client happy.
1490 // "watchpoint". Should be used in conjunction with
1491 // the "watch"/"rwatch"/"awatch" key value pairs.
1492 // "exception" an exception stop reason. Use with
1493 // the "description" key/value pair to describe the
1494 // exceptional event the user should see as the stop
1496 // "description" ascii-hex An ASCII hex string that contains a more descriptive
1497 // reason that the thread stopped. This is only needed
1498 // if none of the key/value pairs are enough to
1499 // describe why something stopped.
1501 // "threads" comma-sep-base16 A list of thread ids for all threads (including
1502 // the thread that we're reporting as stopped) that
1503 // are live in the process right now. lldb may
1504 // request that this be included in the T packet via
1505 // the QListThreadsInStopReply packet earlier in
1506 // the debug session.
1509 // threads:63387,633b2,63424,63462,63486;
1511 // "thread-pcs" comma-sep-base16 A list of pc values for all threads that currently
1512 // exist in the process, including the thread that
1513 // this T packet is reporting as stopped.
1514 // This key-value pair will only be emitted when the
1515 // "threads" key is already included in the T packet.
1516 // The pc values correspond to the threads reported
1517 // in the "threads" list. The number of pcs in the
1518 // "thread-pcs" list will be the same as the number of
1519 // threads in the "threads" list.
1520 // lldb may request that this be included in the T
1521 // packet via the QListThreadsInStopReply packet
1522 // earlier in the debug session.
1525 // thread-pcs:dec14,2cf872b0,2cf8681c,2d02d68c,2cf716a8;
1528 // Since register values can be supplied with this packet, it is often useful
1529 // to return the PC, SP, FP, LR (if any), and FLAGS registers so that separate
1530 // packets don't need to be sent to read each of these registers from each
1533 // If a thread is stopped for no reason (like just because another thread
1534 // stopped, or because when one core stops all cores should stop), use a
1535 // "T" packet with "00" as the signal number and fill in as many key values
1536 // and registers as possible.
1538 // LLDB likes to know why a thread stopped since many thread control
1539 // operations like stepping over a source line, actually are implemented
1540 // by running the process multiple times. If a breakpoint is hit while
1541 // trying to step over a source line and LLDB finds out that a breakpoint
1542 // is hit in the "reason", we will know to stop trying to do the step
1543 // over because something happened that should stop us from trying to
1544 // do the step. If we are at a breakpoint and we disable the breakpoint
1545 // at the current PC and do an instruction single step, knowing that
1546 // we stopped due to a "trace" helps us know that we can continue
1547 // running versus stopping due to a "breakpoint" (if we have two
1548 // breakpoint instruction on consecutive instructions). So the more info
1549 // we can get about the reason a thread stops, the better job LLDB can
1550 // do when controlling your process. A typical GDB server behavior is
1551 // to send a SIGTRAP for breakpoints _and_ also when instruction single
1552 // stepping, in this case the debugger doesn't really know why we
1553 // stopped and it can make it hard for the debugger to control your
1554 // program correctly. What if a real SIGTRAP was delivered to a thread
1555 // while we were trying to single step? We wouldn't know the difference
1556 // with a standard GDB remote server and we could do the wrong thing.
1558 // PRIORITY TO IMPLEMENT
1559 // High. Having the extra information in your stop reply packets makes
1560 // your debug session more reliable and informative.
1561 //----------------------------------------------------------------------
1564 //----------------------------------------------------------------------
1565 // PLATFORM EXTENSION - for use as a GDB remote platform
1566 //----------------------------------------------------------------------
1571 // Get the first process info (qfProcessInfo) or subsequent process
1572 // info (qsProcessInfo) for one or more processes on the remote
1573 // platform. The first call gets the first match and subsequent calls
1574 // to qsProcessInfo gets the subsequent matches. Return an error EXX,
1575 // where XX are two hex digits, when no more matches are available.
1577 // PRIORITY TO IMPLEMENT
1578 // Required. The qfProcessInfo packet can be followed by a ':' and
1579 // some key value pairs. The key value pairs in the command are:
1581 // KEY VALUE DESCRIPTION
1582 // =========== ======== ================================================
1583 // "name" ascii-hex An ASCII hex string that contains the name of
1584 // the process that will be matched.
1585 // "name_match" enum One of: "equals", "starts_with", "ends_with",
1586 // "contains" or "regex"
1587 // "pid" integer A string value containing the decimal process ID
1588 // "parent_pid" integer A string value containing the decimal parent
1590 // "uid" integer A string value containing the decimal user ID
1591 // "gid" integer A string value containing the decimal group ID
1592 // "euid" integer A string value containing the decimal effective user ID
1593 // "egid" integer A string value containing the decimal effective group ID
1594 // "all_users" bool A boolean value that specifies if processes should
1595 // be listed for all users, not just the user that the
1596 // platform is running as
1597 // "triple" string An ASCII triple string ("x86_64",
1598 // "x86_64-apple-macosx", "armv7-apple-ios")
1599 // "args" string A string value containing the process arguments
1600 // separated by the character '-', where each argument is
1601 // hex-encoded. It includes argv[0].
1603 // The response consists of key/value pairs where the key is separated from the
1604 // values with colons and each pair is terminated with a semi colon. For a list
1605 // of the key/value pairs in the response see the "qProcessInfoPID" packet
1608 // Sample packet/response:
1609 // send packet: $qfProcessInfo#00
1610 // read packet: $pid:60001;ppid:59948;uid:7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:x86_64-apple-macosx;#00
1611 // send packet: $qsProcessInfo#00
1612 // read packet: $pid:59992;ppid:192;uid:7746;gid:11;euid:7746;egid:11;name:6d64776f726b6572;triple:x86_64-apple-macosx;#00
1613 // send packet: $qsProcessInfo#00
1614 // read packet: $E04#00
1615 //----------------------------------------------------------------------
1618 //----------------------------------------------------------------------
1619 // PLATFORM EXTENSION - for use as a GDB remote platform
1620 //----------------------------------------------------------------------
1621 // "qLaunchGDBServer"
1624 // Have the remote platform launch a GDB server.
1626 // PRIORITY TO IMPLEMENT
1627 // Required. The qLaunchGDBServer packet must be followed by a ':' and
1628 // some key value pairs. The key value pairs in the command are:
1630 // KEY VALUE DESCRIPTION
1631 // =========== ======== ================================================
1632 // "port" integer A string value containing the decimal port ID or
1633 // zero if the port should be bound and returned
1635 // "host" integer The host that connections should be limited to
1636 // when the GDB server is connected to.
1638 // The response consists of key/value pairs where the key is separated from the
1639 // values with colons and each pair is terminated with a semi colon.
1641 // Sample packet/response:
1642 // send packet: $qLaunchGDBServer:port:0;host:lldb.apple.com;#00
1643 // read packet: $pid:60025;port:50776;#00
1645 // The "pid" key/value pair is only specified if the remote platform launched
1646 // a separate process for the GDB remote server and can be omitted if no
1647 // process was separately launched.
1649 // The "port" key/value pair in the response lets clients know what port number
1650 // to attach to in case zero was specified as the "port" in the sent command.
1651 //----------------------------------------------------------------------
1654 //----------------------------------------------------------------------
1655 // PLATFORM EXTENSION - for use as a GDB remote platform
1656 //----------------------------------------------------------------------
1657 // "qProcessInfoPID:PID"
1660 // Have the remote platform get detailed information on a process by
1661 // ID. PID is specified as a decimal integer.
1663 // PRIORITY TO IMPLEMENT
1666 // The response consists of key/value pairs where the key is separated from the
1667 // values with colons and each pair is terminated with a semi colon.
1669 // The key value pairs in the response are:
1671 // KEY VALUE DESCRIPTION
1672 // =========== ======== ================================================
1673 // "pid" integer Process ID as a decimal integer string
1674 // "ppid" integer Parent process ID as a decimal integer string
1675 // "uid" integer A string value containing the decimal user ID
1676 // "gid" integer A string value containing the decimal group ID
1677 // "euid" integer A string value containing the decimal effective user ID
1678 // "egid" integer A string value containing the decimal effective group ID
1679 // "name" ascii-hex An ASCII hex string that contains the name of the process
1680 // "triple" string A target triple ("x86_64-apple-macosx", "armv7-apple-ios")
1682 // Sample packet/response:
1683 // send packet: $qProcessInfoPID:60050#00
1684 // read packet: $pid:60050;ppid:59948;uid:7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:x86_64-apple-macosx;#00
1685 //----------------------------------------------------------------------
1687 //----------------------------------------------------------------------
1691 // Same as vAttach, except instead of a "pid" you send a process name.
1693 // PRIORITY TO IMPLEMENT
1694 // Low. Only needed for "process attach -n". If the packet isn't supported
1695 // then "process attach -n" will fail gracefully. So you need only to support
1696 // it if attaching to a process by name makes sense for your environment.
1697 //----------------------------------------------------------------------
1699 //----------------------------------------------------------------------
1703 // Same as vAttachName, except that the stub should wait for the next instance
1704 // of a process by that name to be launched and attach to that.
1706 // PRIORITY TO IMPLEMENT
1707 // Low. Only needed to support "process attach -w -n" which will fail
1708 // gracefully if the packet is not supported.
1709 //----------------------------------------------------------------------
1711 //----------------------------------------------------------------------
1712 // "qAttachOrWaitSupported"
1715 // This is a binary "is it supported" query. Return OK if you support
1718 // PRIORITY TO IMPLEMENT
1719 // Low. This is required if you support vAttachOrWait, otherwise no support
1720 // is needed since the standard "I don't recognize this packet" response
1721 // will do the right thing.
1722 //----------------------------------------------------------------------
1724 //----------------------------------------------------------------------
1728 // Same as vAttachWait, except that the stub will attach to a process
1729 // by name if it exists, and if it does not, it will wait for a process
1730 // of that name to appear and attach to it.
1732 // PRIORITY TO IMPLEMENT
1733 // Low. Only needed to implement "process attach -w -i false -n". If
1734 // you don't implement it but do implement -n AND lldb can somehow get
1735 // a process list from your device, it will fall back on scanning the
1736 // process list, and sending vAttach or vAttachWait depending on
1737 // whether the requested process exists already. This is racy,
1738 // however, so if you want to support this behavior it is better to
1739 // support this packet.
1740 //----------------------------------------------------------------------
1742 //----------------------------------------------------------------------
1743 // "jThreadExtendedInfo"
1746 // This packet, which takes its arguments as JSON and sends its reply as
1747 // JSON, allows the gdb remote stub to provide additional information
1748 // about a given thread.
1750 // PRIORITY TO IMPLEMENT
1751 // Low. This packet is only needed if the gdb remote stub wants to
1752 // provide interesting additional information about a thread for the
1755 // This packet takes its arguments in JSON form ( http://www.json.org ).
1756 // At a minimum, a thread must be specified, for example:
1758 // jThreadExtendedInfo:{"thread":612910}
1760 // Because this is a JSON string, the thread number is provided in base10.
1761 // Additional key-value pairs may be provided by lldb to the gdb remote
1762 // stub. For instance, on some versions of macOS, lldb can read offset
1763 // information out of the system libraries. Using those offsets, debugserver
1764 // is able to find the Thread Specific Address (TSD) for a thread and include
1765 // that in the return information. So lldb will send these additional fields
1768 // jThreadExtendedInfo:{"plo_pthread_tsd_base_address_offset":0,"plo_pthread_tsd_base_offset":224,"plo_pthread_tsd_entry_size":8,"thread":612910}
1770 // There are no requirements for what is included in the response. A simple
1771 // reply on a OS X Yosemite / iOS 8 may include the pthread_t value, the
1772 // Thread Specific Data (TSD) address, the dispatch_queue_t value if the thread
1773 // is associated with a GCD queue, and the requested Quality of Service (QoS)
1774 // information about that thread. For instance, a reply may look like:
1776 // {"tsd_address":4371349728,"requested_qos":{"enum_value":33,"constant_name":"QOS_CLASS_USER_INTERACTIVE","printable_name":"User Interactive"},"pthread_t":4371349504,"dispatch_queue_t":140735087127872}
1778 // tsd_address, pthread_t, and dispatch_queue_t are all simple key-value pairs.
1779 // The JSON standard requires that numbers be expressed in base 10 - so all of
1780 // these are. requested_qos is a dictionary with three key-value pairs in it -
1781 // so the UI layer may choose the form most appropriate for displaying to the user.
1783 // Sending JSON over gdb-remote protocol introduces some problems. We may be
1784 // sending strings with arbitrary contents in them, including the '#', '$', and '*'
1785 // characters that have special meaning in gdb-remote protocol and cannot occur
1786 // in the middle of the string. The standard solution for this would be to require
1787 // ascii-hex encoding of all strings, or ascii-hex encode the entire JSON payload.
1789 // Instead, the binary escaping convention is used for JSON data. This convention
1790 // (e.g. used for the X packet) says that if '#', '$', '*', or '}' are to occur in
1791 // the payload, the character '}' (0x7d) is emitted, then the metacharacter is emitted
1792 // xor'ed by 0x20. The '}' character occurs in every JSON payload at least once, and
1793 // '}' ^ 0x20 happens to be ']' so the raw packet characters for a request will look
1796 // jThreadExtendedInfo:{"thread":612910}]
1799 //----------------------------------------------------------------------
1801 //----------------------------------------------------------------------
1802 // "QEnableCompression"
1805 // This packet enables compression of the packets that the debug stub sends to lldb.
1806 // If the debug stub can support compression, it indictes this in the reply of the
1807 // "qSupported" packet. e.g.
1808 // LLDB SENDS: qSupported:xmlRegisters=i386,arm,mips
1809 // STUB REPLIES: qXfer:features:read+;SupportedCompressions=lzfse,zlib-deflate,lz4,lzma;DefaultCompressionMinSize=384
1811 // If lldb knows how to use any of these compression algorithms, it can ask that this
1812 // compression mode be enabled. It may optionally change the minimum packet size
1813 // where compression is used. Typically small packets do not benefit from compression,
1814 // as well as compression headers -- compression is most beneficial with larger packets.
1816 // QEnableCompression:type:zlib-deflate;
1818 // QEnableCompression:type:zlib-deflate;minsize:512;
1820 // The debug stub should reply with an uncompressed "OK" packet to indicate that the
1821 // request was accepted. All further packets the stub sends will use this compression.
1823 // Packets are compressed as the last step before they are sent from the stub, and
1824 // decompressed as the first step after they are received. The packet format in compressed
1825 // mode becomes one of two:
1827 // $N<uncompressed payload>#00
1829 // $C<size of uncompressed payload in base10>:<compressed payload>#00
1831 // Where "#00" is the actual checksum value if noack mode is not enabled. The checksum
1832 // value is for the "N<uncompressed payload>" or
1833 // "C<size of uncompressed payload in base10>:<compressed payload>" bytes in the packet.
1835 // The size of the uncompressed payload in base10 is provided because it will simplify
1836 // decompression if the final buffer size needed is known ahead of time.
1838 // Compression on low-latency connections is unlikely to be an improvement. Particularly
1839 // when the debug stub and lldb are running on the same host. It should only be used
1840 // for slow connections, and likely only for larger packets.
1842 // Example compression algorithsm that may be used include
1845 // The raw DEFLATE format as described in IETF RFC 1951. With the ZLIB library, you
1846 // can compress to this format with an initialization like
1847 // deflateInit2 (&stream, 5, Z_DEFLATED, -15, 8, Z_DEFAULT_STRATEGY)
1848 // and you can decompress with an initialization like
1849 // inflateInit2 (&stream, -15)
1852 // https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)
1853 // https://github.com/Cyan4973/lz4
1854 // The libcompression APIs on darwin systems call this COMPRESSION_LZ4_RAW.
1857 // An Apple proprietary compression algorithm implemented in libcompression.
1860 // libcompression implements "LZMA level 6", the default compression for the
1861 // open source LZMA implementation.
1862 //----------------------------------------------------------------------
1864 //----------------------------------------------------------------------
1865 // "jGetLoadedDynamicLibrariesInfos"
1868 // This packet asks the remote debug stub to send the details about libraries
1869 // being added/removed from the process as a performance optimization.
1871 // There are three ways this packet can be used. All three return a dictionary of
1872 // binary images formatted the same way.
1874 // On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and earlier, the packet is used like
1875 // jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
1876 // where the image_list_address is an array of {void* load_addr, void* mod_date, void* pathname}
1877 // in the inferior process memory (and image_count is the number of elements in this array).
1878 // lldb is using information from the dyld_all_image_infos structure to make these requests to
1879 // debugserver. This use is not supported on macOS 10.12, iOS 10, tvOS 10, watchOS 3 or newer.
1881 // On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer, there are two calls. One requests information
1882 // on all shared libraries:
1883 // jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}
1884 // And the second requests information about a list of shared libraries, given their load addresses:
1885 // jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[8382824135,3258302053,830202858503]}
1887 // The second call is both a performance optimization (instead of having lldb read the mach-o header/load commands
1888 // out of memory with generic read packets) but also adds additional information in the form of the
1889 // filename of the shared libraries (which is not available in the mach-o header/load commands.)
1891 // An example using the OS X 10.11 style call:
1893 // LLDB SENDS: jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
1894 // STUB REPLIES: ${"images":[{"load_address":4294967296,"mod_date":0,"pathname":"/tmp/a.out","uuid":"02CF262C-ED6F-3965-9E14-63538B465CFF","mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":18446744071562067971,"filetype":2},"segments":{"name":"__PAGEZERO","vmaddr":0,"vmsize":4294967296,"fileoff":0,"filesize":0,"maxprot":0},{"name":"__TEXT","vmaddr":4294967296,"vmsize":4096,"fileoff":0,"filesize":4096,"maxprot":7},{"name":"__LINKEDIT","vmaddr":4294971392,"vmsize":4096,"fileoff":4096,"filesize":152,"maxprot":7}}]}#00
1896 // Or pretty-printed,
1898 // STUB REPLIES: ${"images":
1900 // {"load_address":4294967296,
1902 // "pathname":"/tmp/a.out",
1903 // "uuid":"02CF262C-ED6F-3965-9E14-63538B465CFF",
1905 // {"magic":4277009103,
1906 // "cputype":16777223,
1907 // "cpusubtype":18446744071562067971,
1912 // {"name":"__PAGEZERO",
1914 // "vmsize":4294967296,
1919 // {"name":"__TEXT",
1920 // "vmaddr":4294967296,
1926 // {"name":"__LINKEDIT",
1927 // "vmaddr":4294971392,
1939 // This is similar to the qXfer:libraries:read packet, and it could
1940 // be argued that it should be merged into that packet. A separate
1941 // packet was created primarily because lldb needs to specify the
1942 // number of images to be read and the address from which the initial
1943 // information is read. Also the XML DTD would need to be extended
1944 // quite a bit to provide all the information that the DynamicLoaderMacOSX
1945 // would need to work correctly on this platform.
1947 // PRIORITY TO IMPLEMENT
1948 // On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and older: Low. If this packet is absent,
1949 // lldb will read the Mach-O headers/load commands out of memory.
1950 // On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer: High. If this packet is absent,
1951 // lldb will not know anything about shared libraries in the inferior, or where the main
1952 // executable loaded.
1953 //----------------------------------------------------------------------
1955 //----------------------------------------------------------------------
1959 // Ask for the server for thread stop information of all threads.
1961 // PRIORITY TO IMPLEMENT
1962 // Low. This is a performance optimization, which speeds up debugging by avoiding
1963 // multiple round-trips for retrieving thread information. The information from this
1964 // packet can be retrieved using a combination of qThreadStopInfo and m packets.
1965 //----------------------------------------------------------------------
1967 The data in this packet is very similar to the stop reply packets, but is packaged in
1968 JSON and uses JSON arrays where applicable. The JSON output looks like:
1973 "reason":"exception",
1974 "qaddr":140735118423168,
1976 "0":"8000000000000000",
1977 "1":"0000000000000000",
1978 "2":"20fabf5fff7f0000",
1979 "3":"e8f8bf5fff7f0000",
1980 "4":"0100000000000000",
1981 "5":"d8f8bf5fff7f0000",
1982 "6":"b0f8bf5fff7f0000",
1983 "7":"20f4bf5fff7f0000",
1984 "8":"8000000000000000",
1985 "9":"61a8db78a61500db",
1986 "10":"3200000000000000",
1987 "11":"4602000000000000",
1988 "12":"0000000000000000",
1989 "13":"0000000000000000",
1990 "14":"0000000000000000",
1991 "15":"0000000000000000",
1992 "16":"960b000001000000",
1993 "17":"0202000000000000",
1994 "18":"2b00000000000000",
1995 "19":"0000000000000000",
1996 "20":"0000000000000000"
1999 {"address":140734799804592,"bytes":"c8f8bf5fff7f0000c9a59e8cff7f0000"},
2000 {"address":140734799804616,"bytes":"00000000000000000100000000000000"}
2005 It contains an array of dictionaries with all of the key value pairs that are
2006 normally in the stop reply packet, including the expedited registers. The registers are
2007 passed as hex-encoded JSON string in debuggee-endian byte order. Note that the register
2008 numbers are decimal numbers, unlike the stop-reply packet, where they are written in
2009 hex. The packet also contains expedited memory in the "memory" key. This allows the
2010 server to expedite memory that the client is likely to use (e.g., areas around the
2011 stack pointer, which are needed for computing backtraces) and it reduces the packet
2014 On macOS with debugserver, we expedite the frame pointer backchain for a thread
2015 (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for
2016 the previous FP and PC), and follow the backchain. Most backtraces on macOS and
2017 iOS now don't require us to read any memory!
2019 //----------------------------------------------------------------------
2020 // "jGetSharedCacheInfo"
2023 // This packet asks the remote debug stub to send the details about the inferior's
2024 // shared cache. The shared cache is a collection of common libraries/frameworks that
2025 // are mapped into every process at the same address on Darwin systems, and can be
2026 // identified by a load address and UUID.
2029 // LLDB SENDS: jGetSharedCacheInfo:{}
2030 // STUB REPLIES: ${"shared_cache_base_address":140735683125248,"shared_cache_uuid":"DDB8D70C-C9A2-3561-B2C8-BE48A4F33F96","no_shared_cache":false,"shared_cache_private_cache":false]}#00
2032 // PRIORITY TO IMPLEMENT
2033 // Low. When both lldb and the inferior process are running on the same computer, and lldb
2034 // and the inferior process have the same shared cache, lldb may (as an optimization) read
2035 // the shared cache out of its own memory instead of using gdb-remote read packets to read
2036 // them from the inferior process.
2037 //----------------------------------------------------------------------
2039 //----------------------------------------------------------------------
2040 // "qQueryGDBServer"
2043 // Ask the platform for the list of gdbservers we have to connect
2045 // PRIORITY TO IMPLEMENT
2046 // Low. The packet is required to support connecting to gdbserver started
2047 // by the platform instance automatically.
2048 //----------------------------------------------------------------------
2050 If the remote platform automatically started one or more gdbserver instance (without
2051 lldb asking it) then it have to return the list of port number or socket name for
2052 each of them what can be used by lldb to connect to those instances.
2054 The data in this packet is a JSON array of JSON objects with the following keys:
2055 "port": <the port number to connect> (optional)
2056 "socket_name": <the name of the socket to connect> (optional)
2062 { "socket_name": "foo" }