You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[lldb][docs] Fix plaintext markers in Formatter bytecode doc (#171430)
RST uses double backtick for plain text. For single backtick it will try
to resolve it to a reference then fall back to plain text if it doesn't
resolve.
This leads to a lot of warnings like:
formatterbytecode.rst:7: WARNING: 'any' reference target not found:
~/.lldbinit
As seen on the publish-sphinx-docs bot.
Copy file name to clipboardExpand all lines: lldb/docs/resources/formatterbytecode.rst
+78-78Lines changed: 78 additions & 78 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,9 +4,9 @@ Formatter Bytecode
4
4
Background
5
5
----------
6
6
7
-
LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely.
7
+
LLDB provides rich customization options to display data types (see :doc`/use/variable/`). To use custom data formatters, developers need to edit the global ``~/.lldbinit`` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely.
8
8
9
-
An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them.
9
+
An end-to-end example of such a workflow is the Swift ``DebugDescription`` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a ``.lldbsummaries`` section, where LLDB can find them.
10
10
11
11
This document describes a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers.
12
12
@@ -35,11 +35,11 @@ All objects on the data stack must have one of the following data types. These d
35
35
* *String* (UTF-8)
36
36
* *Int* (64 bit)
37
37
* *UInt* (64 bit)
38
-
* *Object* (Basically an `SBValue`)
39
-
* *Type* (Basically an `SBType`)
38
+
* *Object* (Basically an ``SBValue``)
39
+
* *Type* (Basically an ``SBType``)
40
40
* *Selector* (One of the predefine functions)
41
41
42
-
*Object* and *Type* are opaque, they can only be used as a parameters of `call`.
42
+
*Object* and *Type* are opaque, they can only be used as a parameters of ``call``.
43
43
44
44
Instruction set
45
45
---------------
@@ -52,30 +52,30 @@ These instructions manipulate the data stack directly.
52
52
======== ========== ===========================
53
53
Opcode Mnemonic Stack effect
54
54
-------- ---------- ---------------------------
55
-
0x00 `dup` `(x -> x x)`
56
-
0x01 `drop` `(x y -> x)`
57
-
0x02 `pick` `(x ... UInt -> x ... x)`
58
-
0x03 `over` `(x y -> x y x)`
59
-
0x04 `swap` `(x y -> y x)`
60
-
0x05 `rot` `(x y z -> z x y)`
55
+
0x00 ``dup`` ``(x -> x x)``
56
+
0x01 ``drop`` ``(x y -> x)``
57
+
0x02 ``pick`` ``(x ... UInt -> x ... x)``
58
+
0x03 ``over`` ``(x y -> x y x)``
59
+
0x04 ``swap`` ``(x y -> y x)``
60
+
0x05 ``rot`` ``(x y z -> z x y)``
61
61
======== ========== ===========================
62
62
63
63
Control flow
64
64
~~~~~~~~~~~~
65
65
66
-
These manipulate the control stack and program counter. Both `if` and `ifelse` expect a `UInt` at the top of the data stack to represent the condition.
66
+
These manipulate the control stack and program counter. Both ``if`` and ``ifelse`` expect a ``UInt`` at the top of the data stack to represent the condition.
All of these operations are only defined for `Int` and `UInt` and both operands need to be of the same type. The `>>` operator is an arithmetic shift if the parameters are of type `Int`, otherwise it's a logical shift to the right.
109
+
All of these operations are only defined for ``Int`` and ``UInt`` and both operands need to be of the same type. The ``>>`` operator is an arithmetic shift if the parameters are of type ``Int``, otherwise it's a logical shift to the right.
110
110
111
111
======== ========== ===========================
112
112
Opcode Mnemonic Stack effect
113
113
-------- ---------- ---------------------------
114
-
0x30 `+` `(x y -> [x+y])`
115
-
0x31 `-` etc ...
116
-
0x32 `*`
117
-
0x33 `/`
118
-
0x34 `%`
119
-
0x35 `<<`
120
-
0x36 `>>`
121
-
0x40 `~`
122
-
0x41 `|`
123
-
0x42 `^`
124
-
0x50 `=`
125
-
0x51 `!=`
126
-
0x52 `<`
127
-
0x53 `>`
128
-
0x54 `=<`
129
-
0x55 `>=`
114
+
0x30 ``+`` ``(x y -> [x+y])``
115
+
0x31 ``-`` etc ...
116
+
0x32 ``*``
117
+
0x33 ``/``
118
+
0x34 ``%``
119
+
0x35 ``<<``
120
+
0x36 ``>>``
121
+
0x40 ``~``
122
+
0x41 ``|``
123
+
0x42 ``^``
124
+
0x50 ``=``
125
+
0x51 ``!=``
126
+
0x52 ``<``
127
+
0x53 ``>``
128
+
0x54 ``=<``
129
+
0x55 ``>=``
130
130
======== ========== ===========================
131
131
132
132
Function calls
133
133
~~~~~~~~~~~~~~
134
134
135
-
For security reasons the list of functions callable with `call` is predefined. The supported functions are either existing methods on `SBValue`, or string formatting operations.
135
+
For security reasons the list of functions callable with ``call`` is predefined. The supported functions are either existing methods on ``SBValue``, or string formatting operations.
@@ -183,7 +183,7 @@ Most instructions are just a single byte opcode. The only exceptions are the lit
183
183
Embedding
184
184
~~~~~~~~~
185
185
186
-
Expression programs are embedded into an `.lldbformatters` section (an evolution of the Swift `.lldbsummaries` section) that is a dictionary of type names/regexes and descriptions. It consists of a list of records. Each record starts with the following header:
186
+
Expression programs are embedded into an ``.lldbformatters`` section (an evolution of the Swift ``.lldbsummaries`` section) that is a dictionary of type names/regexes and descriptions. It consists of a list of records. Each record starts with the following header:
187
187
188
188
* Version number (ULEB128)
189
189
* Remaining size of the record (minus the header) (ULEB128)
@@ -197,9 +197,9 @@ In version 1, a record consists of a dictionary key, which is a type name or reg
197
197
* Length of the key in bytes (ULEB128)
198
198
* The key (UTF-8)
199
199
200
-
A regex has to start with `^`, which is part of the regular expression.
200
+
A regex has to start with ``^``, which is part of the regular expression.
201
201
202
-
After this comes a flag bitfield, which is a ULEB-encoded `lldb::TypeOptions` bitfield.
202
+
After this comes a flag bitfield, which is a ULEB-encoded ``lldb::TypeOptions`` bitfield.
203
203
204
204
* Flags (ULEB128)
205
205
@@ -215,22 +215,22 @@ The possible function signatures are:
If not specified, the init function defaults to an empty function that just passes the Object along. Its results may be cached and allow common prep work to be done for an Object that can be reused by subsequent calls to the other methods. This way subsequent calls to `@get_child_at_index` can avoid recomputing shared information, for example.
226
+
If not specified, the init function defaults to an empty function that just passes the Object along. Its results may be cached and allow common prep work to be done for an Object that can be reused by subsequent calls to the other methods. This way subsequent calls to ``@get_child_at_index`` can avoid recomputing shared information, for example.
227
227
228
228
While it is more efficient to store multiple programs per type key, this is not a requirement. LLDB will merge all entries. If there are conflicts the result is undefined.
229
229
230
230
Execution model
231
231
~~~~~~~~~~~~~~~
232
232
233
-
Execution begins at the first byte in the program. The program counter of the virtual machine starts at offset 0 of the bytecode and may never move outside the range of the program as defined in the header. The data stack starts with one Object or the result of the `@init` function (`Object+` in the table above).
233
+
Execution begins at the first byte in the program. The program counter of the virtual machine starts at offset 0 of the bytecode and may never move outside the range of the program as defined in the header. The data stack starts with one Object or the result of the ``@init`` function (``Object+`` in the table above).
0 commit comments