Lines Matching +full:docs +full:- +full:lldb +full:- +full:man
3 LLDB has added new GDB server packets to better support multi-threaded and
5 [protocol defined by GDB ](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html#Packets) (and [this page](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Host-I_002fO-Packets.html#Host-I_002fO-Packets) for `vFile` packets).
7 If a packet is restated here it is because LLDB's version has some behaviour
8 difference to GDB's version, or it provides some context for a following LLDB
13 mismatch, then things go wrong very quickly. LLDB makes extensive use of the GDB
23 registers a thread might have. Again with GDB, both sides pre-agree on how the
46 permissions & lldb::ePermissionsReadable ? "r" : "",
47 permissions & lldb::ePermissionsWritable ? "w" : "",
48 permissions & lldb::ePermissionsExecutable ? "x" : "");
55 **Priority To Implement:** High if you want LLDB to be able to JIT code and run
69 **Priority To Implement:** High if you want LLDB to be able to JIT code and run
73 ## "A" - launch args packet
81 GDB remote docs for this:
100 ## "D" - Detach and stay stopped
127 LLDB SENDS: jGetDyldProcessState
131 **Priority To Implement:** Low. This packet is needed to prevent lldb's utility
132 functions for scanning the Objective-C class list from running very early in
149 The default behavior is that debugserver scans the mach-o header and load
157 The second call is both a performance optimization (instead of having lldb read the mach-o header/load commands
159 filename of the shared libraries (which is not available in the mach-o header/load commands.)
163 LLDB SENDS: jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
164 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
167 Or pretty-printed:
174 "uuid":"02CF262C-ED6F-3965-9E14-63538B465CFF",
212 packet was created primarily because lldb needs to specify the
221 lldb will read the Mach-O headers/load commands out of memory.
223 lldb will not know anything about shared libraries in the inferior, or where the main
234 LLDB SENDS: jGetSharedCacheInfo:{}
235 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
240 When both lldb and the inferior process are running on the same computer, and lldb
241 and the inferior process have the same shared cache, lldb may (as an optimization) read
242 the shared cache out of its own memory instead of using gdb-remote read packets to read
265 and the communication link has a non-negligible latency.
285 Tracing technology name, e.g. intel-pt, arm-etm.
312 Tracing technology name, e.g. intel-pt, arm-etm.
355 Non-fatal messages useful for troubleshooting.
366 If per-cpu process tracing is enabled, "tracedThreads" will contain all
369 A side effect of per-cpu tracing is that all the threads of unrelated
373 - iptTrace: trace buffer for a thread or a cpu.
374 - perfContextSwitchTrace: context switch trace for a cpu generated by
376 - procfsCpuInfo: contents of the /proc/cpuinfo file.
384 https://man7.org/linux/man-pages/man2/perf_event_open.2.html for more information about
426 Tracing technology name, e.g. intel-pt, arm-etm.
437 - If "tids" is not provided, then the operation is "process tracing",
439 - Each tracing technology can have different levels of support for "thread
442 ### Intel-Pt
444 intel-pt supports both "thread tracing" and "process tracing".
457 tracing", is stored in an in-memory circular buffer, which keeps the most
464 Size in bytes used by each individual per-thread or per-cpu trace
470 all devices that support intel-pt. A TSC timestamp is generated along
508 started. These secondary traces are correlated with the intel-pt
514 sessions because of its system-wide nature.
528 If "perCpuTracing" is true, then starting the system-wide trace
529 session fails if all the individual per-cpu trace buffers require
535 - Modifying the parameters of an existing trace is not supported. The user
537 - If "process tracing" is attempted and there are individual threads
540 - If "thread tracing" is attempted on a thread already being traced with
575 Tracing technology name, e.g. intel-pt, arm-etm.
591 Get the processor tracing type supported by the gdb-server for the current
605 Tracing technology name, e.g. intel-pt, arm-etm.
614 **Note:** This packet is used by Trace plug-ins (see `lldb_private::Trace.h`) to
615 do live tracing. Specifically, the name of the plug-in should match the name
631 Additional key-value pairs may be provided by lldb to the gdb remote
632 stub. For instance, on some versions of macOS, lldb can read offset
635 that in the return information. So lldb will send these additional fields
650 `tsd_address`, `pthread_t`, and `dispatch_queue_t` are all simple key-value pairs.
651 The JSON standard requires that numbers be expressed in base 10 - so all of
652 these are. `requested_qos` is a dictionary with three key-value pairs in it -
655 Sending JSON over gdb-remote protocol introduces some problems. We may be
657 characters that have special meaning in gdb-remote protocol and cannot occur
659 ascii-hex encoding of all strings, or ascii-hex encode the entire JSON payload.
720 passed as hex-encoded JSON string in debuggee-endian byte order. Note that the register
721 numbers are decimal numbers, unlike the stop-reply packet, where they are written in
735 multiple round-trips for retrieving thread information. The information from this
743 NB: key/value pairs are sent as-is so gdb-remote protocol meta characters
744 (e.g. `#` or `$`) are not acceptable. If any non-printable or
751 Both GDB and LLDB support passing down environment variables. Is it ok to
763 ## QEnvironmentHexEncoded:HEX-ENCODING(NAME=VALUE)
769 environment key-value pair is ascii hex encoded for transmission.
770 This allows values with gdb-remote metacharacters like `#` to be sent.
772 Both GDB and LLDB support passing down environment variables. Is it ok to
786 This packet enables compression of the packets that the debug stub sends to lldb.
790 LLDB SENDS: qSupported:xmlRegisters=i386,arm,mips
791 STUB REPLIES: qXfer:features:read+;SupportedCompressions=lzfse,zlib-deflate,lz4,lzma;
794 If lldb knows how to use any of these compression algorithms, it can ask that this
797 QEnableCompression:type:zlib-deflate;
819 Compression on low-latency connections is unlikely to be an improvement. Particularly
820 when the debug stub and lldb are running on the same host. It should only be used
824 * `zlib-deflate` -
827 deflateInit2 (&stream, 5, Z_DEFLATED, -15, 8, Z_DEFAULT_STRATEGY)
829 inflateInit2 (&stream, -15).
830 * `lz4` -
834 * `lzfse` -
839 * `lzma` -
888 Enable the `threads:` and `thread-pcs:` data in the question-mark packet
897 **Priority To Implement:** Performance. This is a performance benefit to lldb
898 if the thread id's and thread pc values are provided to lldb in the T stop packet
899 -- if they are not provided to lldb, lldb will likely need to send one to
915 * `OK` - if all registers were successfully restored
916 * `EXX` - for any errors
925 all registers and return a non-zero unique integer ID that
936 * `<unsigned int>` - The save_id result is a non-zero unsigned integer value
940 * `EXX` - or an error code in the form of `EXX` where `XX` is a
949 Sets what the server should do when the communication channel with LLDB
979 ## QSetSTDIN:\<ascii-hex-path\> / QSetSTDOUT:\<ascii-hex-path\> / QSetSTDERR:\<ascii-hex-path\>
987 QSetSTDIN:<ascii-hex-path>
988 QSetSTDOUT:<ascii-hex-path>
989 QSetSTDERR:<ascii-hex-path>
997 ## QSetWorkingDir:\<ascii-hex-path\>
1003 QSetWorkingDir:<ascii-hex-path>
1017 communication interfaces (like sockets). Below GDB or LLDB will send this
1019 from GDB/LLDB, and all lines that start with "read packet: " are from the GDB
1037 there are several additions to the response that lldb can parse.
1042 send packet: qSupported:xmlRegisters=i386,arm,mips,arc;multiprocess+;fork-events+;vfork-events+
1044 read packet: qXfer:features:read+;PacketSize=20000;qEcho+;native-signals+;SupportedCompressions=lzfse,zlib-deflate,lz4,lzma;SupportedWatchpointTypes=aarch64-mask,aarch64-bas;
1047 In the example above, three lldb extensions are shown:
1057 * `x86_64` - 64-bit x86-64 watchpoints (1, 2, 4, 8 byte watchpoints
1059 * `aarch64-bas` AArch64 Byte Address Select watchpoints
1061 * `aarch64-mask` AArch64 MASK watchpoints
1062 (any power-of-2 region of memory from 8 to 2GB, aligned)
1064 If nothing is specified, lldb will default to sending power-of-2
1137 * `<unsigned-hex64>` - Load address of the file in big endian encoding
1138 * `E01` - the requested file isn't loaded
1139 * `EXX` - for any other errors
1154 * `name` - `ascii-hex` -
1156 * `name_match` - `enum` -
1163 * `pid` - `integer`- A string value containing the decimal process ID
1164 * `parent_pid` - `integer` - A string value containing the decimal parent process ID
1165 * `uid` - `integer` - A string value containing the decimal user ID
1166 * `gid` - `integer` - A string value containing the decimal group ID
1167 * `euid` - `integer` - A string value containing the decimal effective user ID
1168 * `egid` - `integer` - A string value containing the decimal effective group ID
1169 * `all_users` - `bool` -
1173 * `triple` - `string` -
1174 An ASCII triple string (`x86_64`, `x86_64-apple-macosx`, `armv7-apple-ios`)
1175 * `args` - `string` -
1176 A string value containing the process arguments separated by the character `-`,
1177 where each argument is hex-encoded. It includes `argv[0]`.
1187 read packet: $pid:60001;ppid:59948;uid:7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:x86_64-apple-macosx;#00
1189 read packet: $pid:59992;ppid:192;uid:7746;gid:11;euid:7746;egid:11;name:6d64776f726b6572;triple:x86_64-apple-macosx;#00
1199 Get version information about this implementation of the gdb-remote
1203 implementation of the gdb-remote-protocol server that lldb can
1206 should be sufficiently unique that lldb can unambiguously identify
1207 the origin of the program (for instance, debugserver from lldb) and
1208 the version/submission number/patch level of the program - whatever
1211 The packet follows the key-value pair model, semicolon separated.
1217 Other clients may find other key-value pairs to be useful for identifying
1222 * `name`: the name of your remote server - "debugserver" is the lldb standard
1233 and can help LLDB to work around bugs in a server's implementation when they
1250 LLDB supports a host info call that gets all sorts of details of the system
1258 * `cputype`: is a number that is the mach-o CPU type that is being debugged (base 10)
1259 * `cpusubtype`: is a number that is the mach-o CPU subtype type that is being debugged (base 10)
1260 * `triple`: a string for the target triple (x86_64-apple-macosx) that can be used to specify arch + vendor + os in one entry
1275 * `vm-page-size`: optional, specifies the target system VM page size, base 10.
1276 Needed for the "dirty-pages:" list in the qMemoryRegionInfo
1278 stub. This page size tells lldb how large each dirty page is.
1281 in a 64-bit pointer are significant for addressing,
1283 v8.3 ABIs that use pointer authentication, so lldb
1296 and can help LLDB select the correct plug-ins for the job based on the target
1315 * `port` - `integer` -
1318 * `host` - `integer` -
1323 send packet: $qLaunchGDBServer:port:0;host:lldb.apple.com;#00
1345 **Priority To Implement:** High, launching processes is a key part of LLDB's
1360 * `start:<start-addr>;` - `<start-addr>` is a big endian hex address that is
1362 * `size:<size>;` - `<size>` is a big endian hex byte size of the address
1364 * `permissions:<permissions>;` - `<permissions>` is a string that contains one
1366 * `name:<name>;` - `<name>` is a hex encoded string that contains the name of
1371 * `flags:<flags-string>;` - where `<flags-string>` is a space separated string
1373 is `mt` for AArch64 memory tagging. lldb will
1375 * `type:[<type>][,<type>];` - memory types that apply to this region, e.g.
1377 * `error:<ascii-byte-error-string>;` - where `<ascii-byte-error-string>` is
1380 * `dirty-pages:[<hexaddr>][,<hexaddr];` -
1382 region that are "dirty" -- they have been modified.
1384 be found from the `qHostInfo`'s `page-size` key-value.
1389 listed (`dirty-pages:;`) indicates no dirty pages in
1394 a NULL pointer and are at 0x0) currently lldb expects to get back the size
1395 of the unmapped region -- that is, the distance to the next valid region.
1406 The stub must include `permissions:` key-value on all memory ranges
1407 that are valid to access in the inferior process -- the lack of
1414 This is nice to have, but it isn't necessary. It helps LLDB
1419 code that LLDB has made) and assume that no registers are available
1428 * `EXX` - for any errors
1449 The result should be a comma-separated list of hex-encoded paths.
1457 Request: `qPlatform_mkdir:<hex-file-mode>,<ascii-hex-path>`
1461 2. file path in ascii-hex encoding
1464 * `F<mkdir-return-code>`
1481 Below is an example communication from a client sending an "ls -la" command:
1485 drwxrwxr-x 16 username groupname 4096 Aug 15 21:36 .
1486 drwxr-xr-x 17 username groupname 4096 Aug 10 16:39 ..
1487 -rw-rw-r-- 1 username groupname 73875 Aug 12 16:46 notes.txt
1488 drwxrwxr-x 5 username groupname 4096 Aug 15 21:36 source.cpp
1489 -rw-r--r-- 1 username groupname 2792 Aug 12 16:46 a.out
1490 -rw-r--r-- 1 username groupname 3190 Aug 12 16:46 Makefile
1505 For example on a 64-bit x86 Mac system both 32-bit and 64-bit user processes are possible,
1506 and with Mach-O universal files, the executable file may contain both 32- and
1507 64-bit slices so it may be impossible to know until you're attached to a real
1515 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
1521 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
1526 * `parent-pid`: the process of the parent process (often debugserver will become the parent when attaching)
1527 * `real-uid`: the real user id of the process
1528 * `real-gid`: the real group id of the process
1529 * `effective-uid`: the effective user id of the process
1530 * `effective-gid`: the effective group id of the process
1531 * `cputype`: the Mach-O CPU type of the process (base 16)
1532 * `cpusubtype`: the Mach-O CPU subtype of the process (base 16)
1537 * `main-binary-uuid`: is the UUID of a firmware type binary that the gdb stub knows about
1538 * `main-binary-address`: is the load address of the firmware type binary
1539 * `main-binary-slide`: is the slide of the firmware type binary, if address isn't known
1540 * `binary-addresses`: A comma-separated list of binary load addresses base 16.
1541 lldb will parse the binaries in memory to get UUIDs, then
1555 * `pid` - `integer` - Process ID as a decimal integer string
1556 * `ppid` - `integer` - Parent process ID as a decimal integer string
1557 * `uid` - `integer` - A string value containing the decimal user ID
1558 * `gid` - `integer` - A string value containing the decimal group ID
1559 * `euid` - `integer` - A string value containing the decimal effective user ID
1560 * `egid` - `integer` - A string value containing the decimal effective group ID
1561 * `name` - `ascii-hex` - An ASCII hex string that contains the name of the process
1562 * `triple` - `string` - A target triple (`x86_64-apple-macosx`, `armv7-apple-ios`)
1567 read packet: $pid:60050;ppid:59948;uid:7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:x86_64-apple-macosx;#00
1577 lldb asking it) then it have to return the list of port number or socket name for
1578 each of them what can be used by lldb to connect to those instances.
1598 ## qRegisterInfo\<hex-reg-id\>
1602 With LLDB, for register information, remote GDB servers can add
1622 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
1624 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
1642 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
1644 read packet: $name:rflags;alt-name:flags;bitsize:64;offset:136;encoding:uint;format:hex;set:General Purpose Registers;#00
1672 read packet: $name:stmm0;bitsize:80;offset:208;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:33;dwarf:33;#00
1674 read packet: $name:stmm1;bitsize:80;offset:224;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:34;dwarf:34;#00
1676 read packet: $name:stmm2;bitsize:80;offset:240;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:35;dwarf:35;#00
1678 read packet: $name:stmm3;bitsize:80;offset:256;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:36;dwarf:36;#00
1680 read packet: $name:stmm4;bitsize:80;offset:272;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:37;dwarf:37;#00
1682 read packet: $name:stmm5;bitsize:80;offset:288;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:38;dwarf:38;#00
1684 read packet: $name:stmm6;bitsize:80;offset:304;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:39;dwarf:39;#00
1686 read packet: $name:stmm7;bitsize:80;offset:320;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:40;dwarf:40;#00
1688 read packet: $name:xmm0;bitsize:128;offset:336;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:17;dwarf:17;#00
1690 read packet: $name:xmm1;bitsize:128;offset:352;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:18;dwarf:18;#00
1692 read packet: $name:xmm2;bitsize:128;offset:368;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:19;dwarf:19;#00
1694 read packet: $name:xmm3;bitsize:128;offset:384;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:20;dwarf:20;#00
1696 read packet: $name:xmm4;bitsize:128;offset:400;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:21;dwarf:21;#00
1698 read packet: $name:xmm5;bitsize:128;offset:416;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:22;dwarf:22;#00
1700 read packet: $name:xmm6;bitsize:128;offset:432;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:23;dwarf:23;#00
1702 read packet: $name:xmm7;bitsize:128;offset:448;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:24;dwarf:24;#00
1704 read packet: $name:xmm8;bitsize:128;offset:464;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:25;dwarf:25;#00
1706 read packet: $name:xmm9;bitsize:128;offset:480;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:26;dwarf:26;#00
1708 read packet: $name:xmm10;bitsize:128;offset:496;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:27;dwarf:27;#00
1710 read packet: $name:xmm11;bitsize:128;offset:512;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:28;dwarf:28;#00
1712 read packet: $name:xmm12;bitsize:128;offset:528;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:29;dwarf:29;#00
1714 read packet: $name:xmm13;bitsize:128;offset:544;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:30;dwarf:30;#00
1716 read packet: $name:xmm14;bitsize:128;offset:560;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:31;dwarf:31;#00
1718 read packet: $name:xmm15;bitsize:128;offset:576;encoding:vector;format:vector-uint8;set:Floating Point Registers;gcc:32;dwarf:32;#00
1733 The `offset:` fields should not leave a gap anywhere in the g/G packet -- the
1745 You may end up with a 4-byte gap between gpr3 and fp1 on architectures
1746 that align values like this. The correct offset: value for fp1 is 12 -
1748 in-memory thread structure has an empty 4 bytes for alignment between
1753 * `name` -
1755 * `alt-name` -
1758 * `bitsize` - Size in bits of a register (32, 64, etc). Base 10.
1759 * `offset` -
1764 * `encoding` -
1770 * format -
1776 * `vector-sint8`
1777 * `vector-uint8`
1778 * `vector-sint16`
1779 * `vector-uint16`
1780 * `vector-sint32`
1781 * `vector-uint32`
1782 * `vector-float32`
1783 * `vector-uint128`
1784 * `set`-
1786 * `gcc` -
1795 * `dwarf` -
1803 * `generic` -
1820 * `arg1` - `arg8` (specified for registers that contain function
1822 * `container-regs` -
1832 container-regs:00;
1837 is "0x21", the "container-regs" key/value pair would be:
1839 container-regs:20,21;
1842 These registers are never requested by LLDB via the register read
1845 * `invalidate-regs` -
1852 ax is 0x25, ah is 0x35, and al is 0x39, the "invalidate-regs" key/value
1855 invalidate-regs:0,15,25,35,39;
1860 invalidate-regs:0;
1864 modifying the CPSR register can cause the r8 - r14 and cpsr value to
1876 gdb RSP stubs whereas `qRegisterInfo` was an lldb-only design.
1886 LLDB and GDB both support the `qShlibInfoAddr` packet which is a hint to each
1899 If you have a dynamic loader plug-in in LLDB for your target
1923 This packet is used by LLDB to discover how reliable the connection is by
1932 Notify the remote that LLDB is ready to do symbol lookups on behalf of the
1955 This should be looked up by LLDB then sent back to the server. Include the name
1961 If LLDB cannot find the value, it should respond with only the name. Note that
1967 If LLDB is asked for any symbols that it cannot find, it should send the
1974 If LLDB did find all the symbols and recieves an `OK` it does not need to send
1983 LLDB tries to use the `qThreadStopInfo` packet which is formatted as
1989 to implement better multi-threaded debugging support.
1993 If you need to support multi-threaded or multi-core debugging.
1996 will also hit a breakpoint. This packet allows LLDB to know why all
1998 stopped and allows LLDB to display and control your program
2004 specify in stop reply packets that help LLDB to know more detailed
2011 * `SAA` -
2016 * `TAAkey1:value1;key2:value2;...` -
2023 thread-id of the stopped thread.
2031 * `WAA` - `W` means the process exited and `AA` is the exit status.
2033 * `XAA` - `X` means the process exited and `AA` is signal that caused the program
2036 * `O<ascii-hex-string>` - `O` means `STDOUT` has data that was written to its
2041 ### Lldb Extensions
2046 * `metype` - `unsigned` -
2050 * `mecount` - `unsigned` -
2053 * `medata` - `unsigned` -
2057 * `name` - `string` -
2062 * `hexname` - `ascii-hex` - An ASCII hex string that contains the name of the thread
2063 * `qaddr` - `hex` -
2066 * `reason` - `enum` - The enumeration must be one of:
2067 * `trace` -
2071 * `breakpoint` - a breakpoint set using a `z` packet was hit.
2072 * `trap` - stopped due to user interruption
2073 * `signal` -
2077 * `watchpoint` - Can be used with of the `watch`/`rwatch`/`awatch` key value
2080 * `exception` - an exception stop reason. Use with
2084 * `description` -
2090 For `reason:watchpoint`, `description` is an ascii-hex
2094 a memory region lldb has a watchpoint on.
2102 outside a watched range means lldb should disable the wp,
2103 step, re-enable the wp and continue silently.
2106 0x1004, a 2-byte write to 0x1000 will trigger the watchpoint
2107 (a false positive hit), and lldb needs to disable the
2108 watchpoint at 0x1004, inst-step, then re-enable the watchpoint
2110 would be "0x1004 0 0x1000". lldb needs a known watchpoint address
2114 0x1004, an instruction does an 8-byte write starting at
2116 trap address as 0x1000 - before the watched memory region -
2118 be reported as "0x1004 0 0x1000". lldb will use 0x1004 to
2124 There may be false-positive watchpoint hits on AArch64 as well,
2126 register flag "WPF", "Watchpoint might be False-Positive") and
2127 not currently handled by lldb.
2128 * `threads` - `comma-sep-base16` -
2131 are live in the process right now. lldb may
2140 * `thread-pcs` - `comma-sep-base16` -
2144 This key-value pair will only be emitted when the
2148 `thread-pcs` list will be the same as the number of
2150 lldb may request that this be included in the `T`
2156 thread-pcs:dec14,2cf872b0,2cf8681c,2d02d68c,2cf716a8;
2158 * `addressing_bits` - `unsigned` (optional) -
2160 10. If bits 38..0 in a 64-bit pointer are significant for addressing, then the
2167 * `low_mem_addressing_bits` - `unsigned` (optional) -
2171 * `high_mem_addressing_bits` - `unsigned` (optional) -
2188 LLDB likes to know why a thread stopped since many thread control
2191 trying to step over a source line and LLDB finds out that a breakpoint
2199 we can get about the reason a thread stops, the better job LLDB can
2215 **Priority To Implement:** Low. Only needed for `process attach -n`. If the
2216 packet isn't supported then `process attach -n` will fail gracefully. So you need
2227 Only needed to implement `process attach -w -i false -n`. If
2228 you don't implement it but do implement `-n` AND lldb can somehow get
2240 **Priority To Implement:** Low. Only needed to support `process attach -w -n`
2253 Request: `qPlatform_chmod:<hex-file-mode>,<ascii-hex-path>`
2256 * `F<chmod-return-code>`
2269 File descriptor is in base 16. `F-1,errno` with the errno if an error occurs,
2319 `F-1,errno` with the errno if an error occurs, base 16.
2334 are the constant values in `enum OpenOptions` from LLDB's
2335 [`File.h`](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Host/File.h).
2339 `F-1,errno` with the errno if an error occurs, base 16.
2356 semicolon, followed by the data in the binary-escaped-data encoding.
2370 3. binary-escaped-data to be written
2384 `F-1,errno` with the errno if an error occurs, base 16.
2388 Create a symbolic link (symlink, soft-link) on the target system.
2391 receive: vFile:symlink:<SRC-FILE>,<DST-NAME>
2395 Argument file paths are in ascii-hex encoding.
2408 Argument is a file path in ascii-hex encoding.
2413 ## "x" - Binary memory read
2423 where both `ADDRESS` and `LENGTH` are big-endian base 16 values.
2431 The reply will be the data requested in 8-bit binary data format.
2439 The `0x` prefixes are optional - like most of the gdb-remote packets,
2442 The length of the payload is not provided. A reliable, 8-bit clean,