1 =====================================
2 CodeView Symbol Records
3 =====================================
14 This document describes the usage and serialization format of the various
15 CodeView symbol records that LLVM understands. Like
16 :doc:`CodeView Type Records <CodeViewTypes>`, we describe only the important
17 types which are generated by modern C++ toolchains.
22 Symbol records share one major similarity with :doc:`type records <CodeViewTypes>`:
23 They start with the same :ref:`record prefix <leaf_types>`, which we will not describe
24 again (refer to the previous link for a description). As a result of this, a sequence
25 of symbol records can be processed with largely the same code as that which processes
26 type records. There are several important differences between symbol and type records:
28 * Symbol records only appear in the :doc:`PublicStream`, :doc:`GlobalStream`, and
29 :doc:`Module Info Streams <ModiStream>`.
30 * Type records only appear in the :doc:`TPI & IPI streams <TpiStream>`.
31 * While types are referenced from other CodeView records via :ref:`type indices <type_indices>`,
32 symbol records are referenced by the byte offset of the record in the stream that it appears
34 * Types can reference types (via type indices), and symbols can reference both types (via type
35 indices) and symbols (via offsets), but types can never reference symbols.
36 * There is no notion of :ref:`Leaf Records <leaf_types>` and :ref:`Member Records <member_types>`
37 as there are with types. Every symbol record describes is own length.
38 * Certain special symbol records begin a "scope". For these records, all following records
39 up until the next ``S_END`` record are "children" of this symbol record. For example,
40 given a symbol record which describes a certain function, all local variables of this
41 function would appear following the function up until the corresponding ``S_END`` record.
43 Finally, there are three general categories of symbol record, grouped by where they are legal
44 to appear in a PDB file. Public Symbols (which appear only in the
45 :doc:`publics stream <PublicStream>`), Global Symbols (which appear only in the
46 :doc:`globals stream <GlobalStream>`) and module symbols (which appear in the
47 :doc:`module info stream <ModiStream>`).
55 Public symbols are the CodeView equivalent of DWARF ``.debug_pubnames``. There
56 is one public symbol record for every function or variable in the program that
57 has a mangled name. The :doc:`Publics Stream <PublicStream>`, which contains these
58 records, additionally contains a hash table that allows one to quickly locate a
59 record by mangled name.
64 There is only type of public symbol, an ``S_PUB32`` which describes a mangled
65 name, a flag indicating what kind of symbol it is (e.g. function, variable), and
66 the symbol's address. The :ref:`dbi_section_map_substream` of the
67 :doc:`DBI Stream <DbiStream>` can be consulted to determine what module this address
68 corresponds to, and from there that module's :doc:`module debug stream <ModiStream>`
69 can be consulted to locate full information for the symbol with the given address.
76 While there is one :ref:`public symbol <public_symbols>` for every symbol in the
77 program with `external` linkage, there is one global symbol for every symbol in the
78 program with linkage (including internal linkage). As a result, global symbols do
79 not describe a mangled name *or* an address, since symbols with internal linkage
80 need not have any mangling at all, and also may not have an address. Thus, all
81 global symbols simply refer directly to the full symbol record via a module/offset
84 Similarly to :ref:`public symbols <public_symbols>`, all global symbols are contained
85 in a single :doc:`Globals Stream <GlobalStream>`, which contains a hash table mapping
86 fully qualified name to the corresponding record in the globals stream (which as
87 mentioned, then contains information allowing one to locate the full record in the
88 corresponding module symbol stream).
90 Note that a consequence and limitation of this design is that program-wide lookup
91 by anything other than an exact textually matching fully-qualified name of whatever
92 the compiler decided to emit is impractical. This differs from DWARF, where even
93 though we don't necessarily have O(1) lookup by basename within a given scope (including
94 O(1) scope, we at least have O(n) access within a given scope).
97 Program-wide lookup of names by anything other than an exact textually matching fully
\r
98 qualified name is not possible.
\r
157 S_UNAMESPACE (0x1124)
158 ^^^^^^^^^^^^^^^^^^^^^
160 S_TRAMPOLINE (0x112c)
161 ^^^^^^^^^^^^^^^^^^^^^
172 S_CALLSITEINFO (0x1139)
173 ^^^^^^^^^^^^^^^^^^^^^^^
175 S_FRAMECOOKIE (0x113a)
176 ^^^^^^^^^^^^^^^^^^^^^^
190 S_DEFRANGE_SUBFIELD (0x1140)
191 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
193 S_DEFRANGE_REGISTER (0x1141)
194 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
196 S_DEFRANGE_FRAMEPOINTER_REL (0x1142)
197 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
199 S_DEFRANGE_SUBFIELD_REGISTER (0x1143)
200 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
202 S_DEFRANGE_FRAMEPOINTER_REL_FULL_SCOPE (0x1144)
203 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
205 S_DEFRANGE_REGISTER_REL (0x1145)
206 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
208 S_LPROC32_ID (0x1146)
209 ^^^^^^^^^^^^^^^^^^^^^
211 S_GPROC32_ID (0x1147)
212 ^^^^^^^^^^^^^^^^^^^^^
217 S_INLINESITE (0x114d)
218 ^^^^^^^^^^^^^^^^^^^^^
220 S_INLINESITE_END (0x114e)
221 ^^^^^^^^^^^^^^^^^^^^^^^^^
223 S_PROC_ID_END (0x114f)
224 ^^^^^^^^^^^^^^^^^^^^^^
226 S_FILESTATIC (0x1153)
227 ^^^^^^^^^^^^^^^^^^^^^
229 S_LPROC32_DPC (0x1155)
230 ^^^^^^^^^^^^^^^^^^^^^^
232 S_LPROC32_DPC_ID (0x1156)
233 ^^^^^^^^^^^^^^^^^^^^^^^^^
241 S_HEAPALLOCSITE (0x115e)
242 ^^^^^^^^^^^^^^^^^^^^^^^^
250 .. _module_and_global_symbols:
252 Symbols which can go in either/both of the module info stream & global stream
253 -----------------------------------------------------------------------------
270 S_MANCONSTANT (0x112d)
271 ^^^^^^^^^^^^^^^^^^^^^^