ctf-spec.info revision 1.1.1.1
1 This is ctf-spec.info, produced by makeinfo version 6.8 from 2 ctf-spec.texi. 3 4 Copyright (C) 2021-2022 Free Software Foundation, Inc. 5 6 Permission is granted to copy, distribute and/or modify this document 7 under the terms of the GNU General Public License, Version 3 or any 8 later version published by the Free Software Foundation. A copy of the 9 license is included in the section entitled "GNU General Public 10 License". 11 12 INFO-DIR-SECTION Software development 13 START-INFO-DIR-ENTRY 14 * CTF: (ctf-spec). The CTF file format. 15 END-INFO-DIR-ENTRY 16 17 18 File: ctf-spec.info, Node: Top, Next: Overview, Up: (dir) 19 20 The CTF file format 21 ******************* 22 23 This manual describes version 3 of the CTF file format, which is 24 intended to model the C type system in a fashion that C programs can 25 consume at runtime. 26 27 * Menu: 28 29 * Overview:: 30 * CTF archive:: 31 * CTF dictionaries:: 32 * Index:: 33 34 35 File: ctf-spec.info, Node: Overview, Next: CTF archive, Prev: Top, Up: Top 36 37 Overview 38 ******** 39 40 The CTF file format compactly describes C types and the association 41 between function and data symbols and types: if embedded in ELF objects, 42 it can exploit the ELF string table to reduce duplication further. 43 There is no real concept of namespacing: only top-level types are 44 described, not types scoped to within single functions. 45 46 CTF dictionaries can be "children" of other dictionaries, in a 47 one-level hierarchy: child dictionaries can refer to types in the 48 parent, but the opposite is not sensible (since if you refer to a child 49 type in the parent, the actual type you cited would vary depending on 50 what child was attached). This parent/child definition is recorded in 51 the child, but only as a recommendation: users of the API have to attach 52 parents to children explicitly, and can choose to attach a child to any 53 parent they like, or to none, though doing so might lead to unpleasant 54 consequences like dangling references to types. *Note Type indexes and 55 type IDs::. Type lookups in child dicts that are not associated with a 56 parent at all will fail with 'ECTF_NOPARENT' if a parent type was 57 needed. 58 59 The associated API to generate, merge together, and query this file 60 format will be described in the accompanying 'libctf' manual once it is 61 written. There is no API to modify dictionaries once they've been 62 written out: CTF is a write-once file format. (However, it is always 63 possible to dynamically create a new child dictionary on the fly and 64 attach it to a pre-existing, read-only parent.) 65 66 There are two major pieces to CTF: the "archive" and the 67 "dictionary". Some relatives and ancestors of CTF call dictionaries 68 "containers": the archive format is unique to this variant of CTF. (Much 69 of the source code still uses the old term.) 70 71 The archive file format is a very simple mmappable archive used to 72 group multiple dictionaries together into groups: it is expected to 73 slowly go away and be replaced by other mechanisms, but right now it is 74 an important part of the file format, used to group dictionaries 75 containing types with conflicting definitions in different TUs with the 76 overarching dictionary used to store all other types. (Even when 77 archives go away, the 'libctf' API used to access them will remain, and 78 access the other mechanisms that replace it instead.) 79 80 The CTF dictionary consists of a "preamble", which does not vary 81 between versions of the CTF file format, and a "header" and some number 82 of "sections", which can vary between versions. 83 84 The rest of this specification describes the format of these 85 sections, first for the latest version of CTF, then for all earlier 86 versions supported by 'libctf': the earlier versions are defined in 87 terms of their differences from the next later one. We describe each 88 part of the format first by reproducing the C structure which defines 89 that part, then describing it at greater length in terms of file 90 offsets. 91 92 The description of the file format ends with a description of 93 relevant limits that apply to it. These limits can vary between file 94 format versions. 95 96 This document is quite young, so for now the C code in 'ctf.h' should 97 be presumed correct when this document conflicts with it. 98 99 100 File: ctf-spec.info, Node: CTF archive, Next: CTF dictionaries, Prev: Overview, Up: Top 101 102 1 CTF archives 103 ************** 104 105 The CTF archive format maps names to CTF dictionaries. The names may 106 contain any character other than \0, but for now archives containing 107 slashes in the names may not extract correctly. It is possible to 108 insert multiple members with the same name, but these are quite hard to 109 access reliably (you have to iterate through all the members rather than 110 opening by name) so this is not recommended. 111 112 CTF archives are not themselves compressed: the constituent 113 components, CTF dictionaries, can be compressed. (*Note CTF header::). 114 115 CTF archives usually contain a collection of related dictionaries, 116 one parent and many children of that parent. CTF archives can have a 117 member with a "default name", '.ctf' (which can be represented as 'NULL' 118 in the API). If present, this member is usually the parent of all the 119 children, but it is possible for CTF producers to emit parents with 120 different names if they wish (usually for backward- compatibility 121 purposes). 122 123 '.ctf' sections in ELF objects consist of a single CTF dictionary 124 rather than an archive of dictionaries if and only if the section 125 contains no types with identical names but conflicting definitions: if 126 two conflicting definitions exist, the deduplicator will place the type 127 most commonly referred to by other types in the parent and will place 128 the other type in a child named after the translation unit it is found 129 in, and will emit a CTF archive containing both dictionaries instead of 130 a raw dictionary. All types that refer to such conflicting types are 131 also placed in the per-translation-unit child. 132 133 The definition of an archive in 'ctf.h' is as follows: 134 135 struct ctf_archive 136 { 137 uint64_t ctfa_magic; 138 uint64_t ctfa_model; 139 uint64_t ctfa_nfiles; 140 uint64_t ctfa_names; 141 uint64_t ctfa_ctfs; 142 }; 143 144 typedef struct ctf_archive_modent 145 { 146 uint64_t name_offset; 147 uint64_t ctf_offset; 148 } ctf_archive_modent_t; 149 150 (Note one irregularity here: the 'ctf_archive_t' is not a typedef to 151 'struct ctf_archive', but a different typedef, private to 'libctf', so 152 that things that are not really archives can be made to appear as if 153 they were.) 154 155 All the above items are always in little-endian byte order, 156 regardless of the machine endianness. 157 158 The archive header has the following fields: 159 160 Offset Name Description 161 ------------------------------------------------------------------------------------------ 162 0x00 'uint64_t ctfa_magic' The magic number for archives, 'CTFA_MAGIC': 163 0x8b47f2a4d7623eeb. 164 165 0x08 'uint64_t ctfa_model' The data model for this archive: an arbitrary integer 166 that serves no purpose but to be handed back by the 167 libctf API. *Note Data models::. 168 169 0x10 'uint64_t ctfa_nfiles' The number of CTF dictionaries in this archive. 170 171 0x18 'uint64_t ctfa_names' Offset of the name table, in bytes from the start of 172 the archive. The name table is an array of 'struct 173 ctf_archive_modent_t[ctfa_nfiles]'. 174 175 0x20 'uint64_t ctfa_ctfs' Offset of the CTF table. Each element starts with a 176 'uint64_t' size, followed by a CTF dictionary. 177 178 179 The array pointed to by 'ctfa_names' is an array of entries of 180 'ctf_archive_modent': 181 182 Offset Name Description 183 --------------------------------------------------------------------------------- 184 0x00 'uint64_t name_offset' Offset of this name, in bytes from the start 185 of the archive. 186 187 0x08 'uint64_t ctf_offset' Offset of this CTF dictionary, in bytes from 188 the start of the archive. 189 190 191 The 'ctfa_names' array is sorted into ASCIIbetical order by name 192 (i.e. by the result of dereferencing the 'name_offset'). 193 194 The archive file also contains a name table and a table of CTF 195 dictionaries: these are pointed to by the structures above. The name 196 table is a simple strtab which is not required to be sorted; the 197 dictionary array is described above in the entry for 'ctfa_ctfs'. 198 199 The relative order of these various parts is not defined, except that 200 the header naturally always comes first. 201 202 203 File: ctf-spec.info, Node: CTF dictionaries, Next: Index, Prev: CTF archive, Up: Top 204 205 2 CTF dictionaries 206 ****************** 207 208 CTF dictionaries consist of a header, starting with a premable, and a 209 number of sections. 210 211 * Menu: 212 213 * CTF Preamble:: 214 * CTF header:: 215 * The type section:: 216 * The symtypetab sections:: 217 * The variable section:: 218 * The label section:: 219 * The string section:: 220 * Data models:: 221 * Limits of CTF:: 222 223 224 File: ctf-spec.info, Node: CTF Preamble, Next: CTF header, Up: CTF dictionaries 225 226 2.1 CTF Preamble 227 ================ 228 229 The preamble is the only part of the CTF dictionary whose format cannot 230 vary between versions. It is never compressed. It is correspondingly 231 simple: 232 233 typedef struct ctf_preamble 234 { 235 unsigned short ctp_magic; 236 unsigned char ctp_version; 237 unsigned char ctp_flags; 238 } ctf_preamble_t; 239 240 '#define's are provided under the names 'cth_magic', 'cth_version' 241 and 'cth_flags' to make the fields of the 'ctf_preamble_t' appear to be 242 part of the 'ctf_header_t', so consuming programs rarely need to 243 consider the existence of the preamble as a separate structure. 244 245 Offset Name Description 246 ------------------------------------------------------------------------------- 247 0x00 'unsigned short ctp_magic' The magic number for CTF 248 dictionaries, 'CTF_MAGIC': 0xdff2. 249 250 0x02 'unsigned char ctp_version' The version number of this CTF 251 dictionary. 252 253 0x03 'ctp_flags' Flags for this CTF file. 254 *Note CTF file-wide flags::. 255 256 Every element of a dictionary must be naturally aligned unless 257 otherwise specified. (This restriction will be lifted in later 258 versions.) 259 260 CTF dictionaries are stored in the native endianness of the system 261 that generates them: the consumer (e.g., 'libctf') can detect whether to 262 endian-flip a CTF dictionary by inspecting the 'ctp_magic'. (If it 263 appears as 0xf2df, endian-flipping is needed.) 264 265 The version of the CTF dictionary can be determined by inspecting 266 'ctp_version'. The following versions are currently valid, and 'libctf' 267 can read all of them: 268 269 Version Number Description 270 ------------------------------------------------------------------------------------------- 271 'CTF_VERSION_1' 1 First version, rare. Very similar to Solaris CTF. 272 273 'CTF_VERSION_1_UPGRADED_3' 2 First version, upgraded to v3 or higher and 274 written out again. Name may change. Very rare. 275 276 'CTF_VERSION_2' 3 Second version, with many range limits lifted. 277 278 'CTF_VERSION_3' 4 Third and current version, documented here. 279 280 This section documents 'CTF_VERSION_3'. 281 282 * Menu: 283 284 * CTF file-wide flags:: 285 286 287 File: ctf-spec.info, Node: CTF file-wide flags, Up: CTF Preamble 288 289 2.1.1 CTF file-wide flags 290 ------------------------- 291 292 The preamble contains bitflags in its 'ctp_flags' field that describe 293 various file-wide properties. Some of the flags are valid only for 294 particular file-format versions, which means the flags can be used to 295 fix file-format bugs. Consumers that see unknown flags should 296 accordingly assume that the dictionary is not comprehensible, and refuse 297 to open them. 298 299 The following flags are currently defined. Many are bug workarounds, 300 valid only in CTFv3, and will not be valid in any future versions: the 301 same values may be reused for other flags in v4+. 302 303 Flag Versions Value Meaning 304 --------------------------------------------------------------------------------------- 305 'CTF_F_COMPRESS' All 0x1 Compressed with zlib 306 'CTF_F_NEWFUNCINFO' 3 only 0x2 "New-format" func info section. 307 'CTF_F_IDXSORTED' 3+ 0x4 The index section is in sorted order 308 'CTF_F_DYNSTR' 3 only 0x8 The external strtab is in '.dynstr' and the 309 symtab used is '.dynsym'. 310 *Note The string section:: 311 312 'CTF_F_NEWFUNCINFO' and 'CTF_F_IDXSORTED' relate to the function info 313 and data object sections. *Note The symtypetab sections::. 314 315 Further flags (and further compression methods) wil be added in 316 future. 317 318 319 File: ctf-spec.info, Node: CTF header, Next: The type section, Prev: CTF Preamble, Up: CTF dictionaries 320 321 2.2 CTF header 322 ============== 323 324 The CTF header is the first part of a CTF dictionary, including the 325 preamble. All parts of it other than the preamble (*note CTF 326 Preamble::) can vary between CTF file versions and are never compressed. 327 It contains things that apply to the dictionary as a whole, and a table 328 of the sections into which the rest of the dictionary is divided. The 329 sections tile the file: each section runs from the offset given until 330 the start of the next section. Only the last section cannot follow this 331 rule, so the header has a length for it instead. 332 333 All section offsets, here and in the rest of the CTF file, are 334 relative to the _end_ of the header. (This is annoyingly different to 335 how offsets in CTF archives are handled.) 336 337 This is the first structure to include offsets into the string table, 338 which are not straight references because CTF dictionaries can include 339 references into the ELF string table to save space, as well as into the 340 string table internal to the CTF dictionary. *Note The string section:: 341 for more on these. Offset 0 is always the null string. 342 343 typedef struct ctf_header 344 { 345 ctf_preamble_t cth_preamble; 346 uint32_t cth_parlabel; 347 uint32_t cth_parname; 348 uint32_t cth_cuname; 349 uint32_t cth_lbloff; 350 uint32_t cth_objtoff; 351 uint32_t cth_funcoff; 352 uint32_t cth_objtidxoff; 353 uint32_t cth_funcidxoff; 354 uint32_t cth_varoff; 355 uint32_t cth_typeoff; 356 uint32_t cth_stroff; 357 uint32_t cth_strlen; 358 } ctf_header_t; 359 360 In detail: 361 362 Offset Name Description 363 ----------------------------------------------------------------------------------------------- 364 0x00 'ctf_preamble_t cth_preamble' The preamble (conceptually embedded in the header). 365 *Note CTF Preamble:: 366 367 0x04 'uint32_t cth_parlabel' The parent label, if deduplication happened against 368 a specific label: a strtab offset. 369 *Note The label section::. Currently unused and 370 always 0, but may be used in future when semantics 371 are attached to the label section. 372 373 0x08 'uint32_t cth_parname' The name of the parent dictionary deduplicated 374 against: a strtab offset. Interpretation is up to 375 the consumer (usually a CTF archive member name). 376 0 (the null string) if this is not a child 377 dictionary. 378 379 0x1c 'uint32_t cth_cuname' The name of the compilation unit, for consumers 380 like GDB that want to know the name of CUs 381 associated with single CUs: a strtab offset. 0 if 382 this dictionary describes types from many CUs. 383 384 0x10 'uint32_t cth_lbloff' The offset of the label section, which tiles the 385 type space into named regions. 386 *Note The label section::. 387 388 0x14 'uint32_t cth_objtoff' The offset of the data object symtypetab section, 389 which maps ELF data symbols to types. 390 *Note The symtypetab sections::. 391 392 0x18 'uint32_t cth_funcoff' The offset of the function info symtypetab section, 393 which maps ELF function symbols to a return type 394 and arg types. *Note The symtypetab sections::. 395 396 0x1c 'uint32_t cth_objtidxoff' The offset of the object index section, which maps 397 ELF object symbols to entries in the data object 398 section. *Note The symtypetab sections::. 399 400 0x20 'uint32_t cth_funcidxoff' The offset of the function info index section, 401 which maps ELF function symbols to entries in the 402 function info section. 403 *Note The symtypetab sections::. 404 405 0x24 'uint32_t cth_varoff' The offset of the variable section, which maps 406 string names to types. 407 *Note The variable section::. 408 409 0x28 'uint32_t cth_typeoff' The offset of the type section, the core of CTF, 410 which describes types using variable-length array 411 elements. *Note The type section::. 412 413 0x2c 'uint32_t cth_stroff' The offset of the string section. 414 *Note The string section::. 415 416 0x30 'uint32_t cth_strlen' The length of the string section (not an offset!). 417 The CTF file ends at this point. 418 419 420 Everything from this point on (until the end of the file at 421 'cth_stroff' + 'cth_strlen') is compressed with zlib if 'CTF_F_COMPRESS' 422 is set in the preamble's 'ctp_flags'. 423 424 425 File: ctf-spec.info, Node: The type section, Next: The symtypetab sections, Prev: CTF header, Up: CTF dictionaries 426 427 2.3 The type section 428 ==================== 429 430 This section is the most important section in CTF, describing all the 431 top-level types in the program. It consists of an array of type 432 structures, each of which describes a type of some "kind": each kind of 433 type has some amount of variable-length data associated with it (some 434 kinds have none). The amount of variable-length data associated with a 435 given type can be determined by inspecting the type, so the reading code 436 can walk through the types in sequence at opening time. 437 438 Each type structure is one of a set of overlapping structures in a 439 discriminated union of sorts: the variable-length data for each type 440 immediately follows the type's type structure. Here's the largest of 441 the overlapping structures, which is only needed for huge types and so 442 is very rarely seen: 443 444 typedef struct ctf_type 445 { 446 uint32_t ctt_name; 447 uint32_t ctt_info; 448 __extension__ 449 union 450 { 451 uint32_t ctt_size; 452 uint32_t ctt_type; 453 }; 454 uint32_t ctt_lsizehi; 455 uint32_t ctt_lsizelo; 456 } ctf_type_t; 457 458 Here's the much more common smaller form: 459 460 typedef struct ctf_stype 461 { 462 uint32_t ctt_name; 463 uint32_t ctt_info; 464 __extension__ 465 union 466 { 467 uint32_t ctt_size; 468 uint32_t ctt_type; 469 }; 470 } ctf_type_t; 471 472 If 'ctt_size' is the #define 'CTF_LSIZE_SENT', 0xffffffff, this type 473 is described by a 'ctf_type_t': otherwise, a 'ctf_stype_t'. 474 475 Here's what the fields mean: 476 477 Offset Name Description 478 ----------------------------------------------------------------------------------------------------- 479 0x00 'uint32_t ctt_name' Strtab offset of the type name, if any (0 if none). 480 481 0x04 'uint32_t ctt_info' The "info word", containing information on the kind 482 of this type, its variable-length data and whether 483 it is visible to name lookup. See 484 *Note The info word::. 485 486 0x08 'uint32_t ctt_size' The size of this type, if this type is of a kind for 487 which a size needs to be recorded (constant-size 488 types don't need one). If this is 'CTF_LSIZE_SENT', 489 this type is a huge type described by 'ctf_type_t'. 490 491 0x08 'uint32_t ctt_type' The type this type refers to, if this type is of a 492 kind which refers to other types (like a pointer). 493 All such types are fixed-size, and no types that are 494 variable-size refer to other types, so 'ctt_size' 495 and 'ctt_type' overlap. All type kinds that use 496 'ctt_type' are described by 'ctf_stype_t', not 497 'ctf_type_t'. *Note Type indexes and type IDs::. 498 499 0x0c ('ctf_type_t' 'uint32_t ctt_lsizehi' The high 32 bits of the size of a very large type. 500 only) The 'CTF_TYPE_LSIZE' macro can be used to get a 501 64-bit size out of this field and the next one. 502 'CTF_SIZE_TO_LSIZE_HI' splits the 'ctt_lsizehi' out 503 of it again. 504 505 0x10 ('ctf_type_t' 'uint32_t ctt_lsizelo' The low 32 bits of the size of a very large type. 506 only) 'CTF_SIZE_TO_LSIZE_LO' splits the 'ctt_lsizelo' out 507 of a 64-bit size. 508 509 Two aspects of this need further explanation: the info word, and what 510 exactly a type ID is and how you determine it. (Information on the 511 various type-kind- dependent things, like whether 'ctt_size' or 512 'ctt_type' is used, is described in the section devoted to each kind.) 513 514 * Menu: 515 516 * The info word:: 517 * Type indexes and type IDs:: 518 * Type kinds:: 519 * Integer types:: 520 * Floating-point types:: 521 * Slices:: 522 * Pointers typedefs and cvr-quals:: 523 * Arrays:: 524 * Function pointers:: 525 * Enums:: 526 * Structs and unions:: 527 * Forward declarations:: 528 529 530 File: ctf-spec.info, Node: The info word, Next: Type indexes and type IDs, Up: The type section 531 532 2.3.1 The info word, ctt_info 533 ----------------------------- 534 535 The info word is a bitfield split into three parts. From MSB to LSB: 536 537 Bit offset Name Description 538 ------------------------------------------------------------------------------------------ 539 26-31 'kind' Type kind: *note Type kinds::. 540 541 25 'isroot' 1 if this type is visible to name lookup 542 543 0-24 'vlen' Length of variable-length data for this type (some kinds only). 544 The variable-length data directly follows the 'ctf_type_t' or 545 'ctf_stype_t'. This is a kind-dependent array length value, 546 not a length in bytes. Some kinds have no variable-length 547 data, or fixed-size variable-length data, and do not use this 548 value. 549 550 The most mysterious of these is undoubtedly 'isroot'. This indicates 551 whether types with names (nonzero 'ctt_name') are visible to name 552 lookup: if zero, this type is considered a "non-root type" and you can't 553 look it up by name at all. Multiple types with the same name in the 554 same C namespace (struct, union, enum, other) can exist in a single 555 dictionary, but only one of them may have a nonzero value for 'isroot'. 556 'libctf' validates this at open time and refuses to open dictionaries 557 that violate this constraint. 558 559 Historically, this feature was introduced for the encoding of 560 bitfields (*note Integer types::): for instance, int bitfields will all 561 be named 'int' with different widths or offsets, but only the full-width 562 one at offset zero is wanted when you look up the type named 'int'. 563 With the introduction of slices (*note Slices::) as a more general 564 bitfield encoding mechanism, this is less important, but we still use 565 non-root types to handle conflicts if the linker API is used to fuse 566 multiple translation units into one dictionary and those translation 567 units contain types with the same name and conflicting definitions. (We 568 do not discuss this further here, because the linker never does this: 569 only specialized type mergers do, like that used for the Linux kernel. 570 The libctf documentation will describe this in more detail.) 571 572 The 'CTF_TYPE_INFO' macro can be used to compose an info word from a 573 'kind', 'isroot', and 'vlen'; 'CTF_V2_INFO_KIND', 'CTF_V2_INFO_ISROOT' 574 and 'CTF_V2_INFO_VLEN' pick it apart again. 575 576 577 File: ctf-spec.info, Node: Type indexes and type IDs, Next: Type kinds, Prev: The info word, Up: The type section 578 579 2.3.2 Type indexes and type IDs 580 ------------------------------- 581 582 Types are referred to within the CTF file via "type IDs". A type ID is 583 a number from 0 to 2^32, from a space divided in half. Types 2^31-1 and 584 below are in the "parent range": these IDs are used for dictionaries 585 that have not had any other dictionary 'ctf_import'ed into it as a 586 parent. Both completely standalone dictionaries and parent dictionaries 587 with children hanging off them have types in this range. Types 2^31 and 588 above are in the "child range": only types in child dictionaries are in 589 this range. 590 591 These IDs appear in 'ctf_type_t.ctt_type' (*note The type section::), 592 but the types themselves have no visible ID: quite intentionally, 593 because adding an ID uses space, and every ID is different so they don't 594 compress well. The IDs are implicit: at open time, the consumer walks 595 through the entire type section and counts the types in the type 596 section. The type section is an array of variable-length elements, so 597 each entry could be considered as having an index, starting from 1. We 598 count these indexes and associate each with its corresponding 599 'ctf_type_t' or 'ctf_stype_t'. 600 601 Lookups of types with IDs in the parent space look in the parent 602 dictionary if this dictionary has one associated with it; lookups of 603 types with IDs in the child space error out if the dictionary does not 604 have a parent, and otherwise convert the ID into an index by shaving off 605 the top bit and look up the index in the child. 606 607 These properties mean that the same dictionary can be used as a 608 parent of child dictionaries and can also be used directly with no 609 children at all, but a dictionary created as a child dictionary must 610 always be associated with a parent -- usually, the same parent -- 611 because its references to its own types have the high bit turned on and 612 this is only flipped off again if this is a child dictionary. (This is 613 not a problem, because if you _don't_ associate the child with a parent, 614 any references within it to its parent types will fail, and there are 615 almost certain to be many such references, or why is it a child at all?) 616 617 This does mean that consumers should keep a close eye on the 618 distinction between type IDs and type indexes: if you mix them up, 619 everything will appear to work as long as you're only using parent 620 dictionaries or standalone dictionaries, but as soon as you start using 621 children, everything will fail horribly. 622 623 Type index zero, and type ID zero, are used to indicate that this 624 type cannot be represented in CTF as currently constituted: they are 625 emitted by the compiler, but all type chains that terminate in the 626 unknown type are erased at link time (structure fields that use them 627 just vanish, etc). So you will probably never see a use of type zero 628 outside the symtypetab sections, where they serve as sentinels of sorts, 629 to indicate symbols with no associated type. 630 631 The macros 'CTF_V2_TYPE_TO_INDEX' and 'CTF_V2_INDEX_TO_TYPE' may help 632 in translation between types and indexes: 'CTF_V2_TYPE_ISPARENT' and 633 'CTF_V2_TYPE_ISCHILD' can be used to tell whether a given ID is in the 634 parent or child range. 635 636 It is quite possible and indeed common for type IDs to point forward 637 in the dictionary, as well as backward. 638 639 640 File: ctf-spec.info, Node: Type kinds, Next: Integer types, Prev: Type indexes and type IDs, Up: The type section 641 642 2.3.3 Type kinds 643 ---------------- 644 645 Every type in CTF is of some "kind". Each kind is some variety of C 646 type: all structures are a single kind, as are all unions, all pointers, 647 all arrays, all integers regardless of their bitfield width, etc. The 648 kind of a type is given in the 'kind' field of the 'ctt_info' word 649 (*note The info word::). 650 651 The space of type kinds is only a quarter full so far, so there is 652 plenty of room for expansion. It is likely that in future versions of 653 the file format, types with smaller kinds will be more efficiently 654 encoded than types with larger kinds, so their numerical value will 655 actually start to matter in future. (So these IDs will probably change 656 their numerical values in a later release of this format, to move more 657 frequently-used kinds like structures and cv-quals towards the top of 658 the space, and move rarely-used kinds like integers downwards. Yes, 659 integers are rare: how many kinds of 'int' are there in a program? 660 They're just very frequently _referenced_.) 661 662 Here's the set of kinds so far. Each kind has a '#define' associated 663 with it, also given here. 664 665 Kind Macro Purpose 666 ---------------------------------------------------------------------------------------- 667 0 'CTF_K_UNKNOWN' Indicates a type that cannot be represented in CTF, or that 668 is being skipped. It is very similar to type ID 0, except 669 that you can have _multiple_, distinct types of kind 670 'CTF_K_UNKNOWN'. 671 672 1 'CTF_K_INTEGER' An integer type. *Note Integer types::. 673 674 2 'CTF_K_FLOAT' A floating-point type. *Note Floating-point types::. 675 676 3 'CTF_K_POINTER' A pointer. *Note Pointers typedefs and cvr-quals::. 677 678 4 'CTF_K_ARRAY' An array. *Note Arrays::. 679 680 5 'CTF_K_FUNCTION' A function pointer. *Note Function pointers::. 681 682 6 'CTF_K_STRUCT' A structure. *Note Structs and unions::. 683 684 7 'CTF_K_UNION' A union. *Note Structs and unions::. 685 686 8 'CTF_K_ENUM' An enumerated type. *Note Enums::. 687 688 9 'CTF_K_FORWARD' A forward. *Note Forward declarations::. 689 690 10 'CTF_K_TYPEDEF' A typedef. *Note Pointers typedefs and cvr-quals::. 691 692 11 'CTF_K_VOLATILE' A volatile-qualified type. 693 *Note Pointers typedefs and cvr-quals::. 694 695 12 'CTF_K_CONST' A const-qualified type. 696 *Note Pointers typedefs and cvr-quals::. 697 698 13 'CTF_K_RESTRICT' A restrict-qualified type. 699 *Note Pointers typedefs and cvr-quals::. 700 701 14 'CTF_K_SLICE' A slice, a change of the bit-width or offset of some other 702 type. *Note Slices::. 703 704 Now we cover all type kinds in turn. Some are more complicated than 705 others. 706 707 708 File: ctf-spec.info, Node: Integer types, Next: Floating-point types, Prev: Type kinds, Up: The type section 709 710 2.3.4 Integer types 711 ------------------- 712 713 Integral types are all represented as types of kind 'CTF_K_INTEGER'. 714 These types fill out 'ctt_size' in the 'ctf_stype_t' with the size in 715 bytes of the integral type in question. They are always represented by 716 'ctf_stype_t', never 'ctf_type_t'. Their variable-length data is one 717 'uint32_t' in length: 'vlen' in the info word should be disregarded and 718 is always zero. 719 720 The variable-length data for integers has multiple items packed into 721 it much like the info word does. 722 723 Bit offset Name Description 724 ----------------------------------------------------------------------------------- 725 24-31 Encoding The desired display representation of this integer. You 726 can extract this field with the 'CTF_INT_ENCODING' 727 macro. See below. 728 729 16-23 Offset The offset of this integral type in bits from the start 730 of its enclosing structure field, adjusted for 731 endianness: *note Structs and unions::. You can extract 732 this field with the 'CTF_INT_OFFSET' macro. 733 734 0-15 Bit-width The width of this integral type in bits. You can 735 extract this field with the 'CTF_INT_BITS' macro. 736 737 If you choose, bitfields can be represented using the things above as 738 a sort of integral type with the 'isroot' bit flipped off and the offset 739 and bits values set in the vlen word: you can populate it with the 740 'CTF_INT_DATA' macro. (But it may be more convenient to represent them 741 using slices of a full-width integer: *note Slices::.) 742 743 Integers that are bitfields usually have a 'ctt_size' rounded up to 744 the nearest power of two in bytes, for natural alignment (e.g. a 17-bit 745 integer would have a 'ctt_size' of 4). However, not all types are 746 naturally aligned on all architectures: packed structures may in theory 747 use integral bitfields with different 'ctt_size', though this is rarely 748 observed. 749 750 The "encoding" for integers is a bit-field comprised of the values 751 below, which consumers can use to decide how to display values of this 752 type: 753 754 Offset Name Description 755 -------------------------------------------------------------------------------------------------------- 756 0x01 'CTF_INT_SIGNED' If set, this is a signed int: if false, unsigned. 757 758 0x02 'CTF_INT_CHAR' If set, this is a char type. It is platform-dependent whether unadorned 759 'char' is signed or not: the 'CTF_CHAR' macro produces an integral type 760 suitable for the definition of 'char' on this platform. 761 762 0x04 'CTF_INT_BOOL' If set, this is a boolean type. (It is theoretically possible to turn 763 this and 'CTF_INT_CHAR' on at the same time, but it is not clear what 764 this would mean.) 765 766 0x08 'CTF_INT_VARARGS' If set, this is a varargs-promoted value in a K&R function definition. 767 This is not currently produced or consumed by anything that we know of: 768 it is set aside for future use. 769 770 The GCC "'Complex int'" and fixed-point extensions are not yet 771 supported: references to such types will be emitted as type 0. 772 773 774 File: ctf-spec.info, Node: Floating-point types, Next: Slices, Prev: Integer types, Up: The type section 775 776 2.3.5 Floating-point types 777 -------------------------- 778 779 Floating-point types are all represented as types of kind 'CTF_K_FLOAT'. 780 Like integers, These types fill out 'ctt_size' in the 'ctf_stype_t' with 781 the size in bytes of the floating-point type in question. They are 782 always represented by 'ctf_stype_t', never 'ctf_type_t'. 783 784 This part of CTF shows many rough edges in the more obscure corners 785 of floating-point handling, and is likely to change in format v4. 786 787 The variable-length data for floats has multiple items packed into it 788 just like integers do: 789 790 Bit offset Name Description 791 ------------------------------------------------------------------------------------------- 792 24-31 Encoding The desired display representation of this float. You can 793 extract this field with the 'CTF_FP_ENCODING' macro. See below. 794 795 16-23 Offset The offset of this floating-point type in bits from the start of 796 its enclosing structure field, adjusted for endianness: 797 *note Structs and unions::. You can extract this field with the 798 'CTF_FP_OFFSET' macro. 799 800 0-15 Bit-width The width of this floating-point type in bits. You can extract 801 this field with the 'CTF_FP_BITS' macro. 802 803 The purpose of the floating-point offset and bit-width is somewhat 804 opaque, since there are no such things as floating-point bitfields in C: 805 the bit-width should be filled out with the full width of the type in 806 bits, and the offset should always be zero. It is likely that these 807 fields will go away in the future. As with integers, you can use 808 'CTF_FP_DATA' to assemble one of these vlen items from its component 809 parts. 810 811 The "encoding" for floats is not a bitfield but a simple value 812 indicating the display representation. Many of these are unused, relate 813 to Solaris-specific compiler extensions, and will be recycled in future: 814 some are unused and will become used in future. 815 816 Offset Name Description 817 ---------------------------------------------------------------------------------------------- 818 1 'CTF_FP_SINGLE' This is a single-precision IEEE 754 'float'. 819 2 'CTF_FP_DOUBLE' This is a double-precision IEEE 754 'double'. 820 3 'CTF_FP_CPLX' This is a 'Complex float'. 821 4 'CTF_FP_DCPLX' This is a 'Complex double'. 822 5 'CTF_FP_LDCPLX' This is a 'Complex long double'. 823 6 'CTF_FP_LDOUBLE' This is a 'long double'. 824 7 'CTF_FP_INTRVL' This is a 'float' interval type, a Solaris-specific extension. 825 Unused: will be recycled. 826 8 'CTF_FP_DINTRVL' This is a 'double' interval type, a Solaris-specific 827 extension. Unused: will be recycled. 828 9 'CTF_FP_LDINTRVL' This is a 'long double' interval type, a Solaris-specific 829 extension. Unused: will be recycled. 830 10 'CTF_FP_IMAGRY' This is a the imaginary part of a 'Complex float'. Not 831 currently generated. May change. 832 11 'CTF_FP_DIMAGRY' This is a the imaginary part of a 'Complex double'. Not 833 currently generated. May change. 834 12 'CTF_FP_LDIMAGRY' This is a the imaginary part of a 'Complex long double'. Not 835 currently generated. May change. 836 837 The use of the complex floating-point encodings is obscure: it is 838 possible that 'CTF_FP_CPLX' is meant to be used for only the real part 839 of complex types, and 'CTF_FP_IMAGRY' et al for the imaginary part - but 840 for now, we are emitting 'CTF_FP_CPLX' to cover the entire type, with no 841 way to get at its constituent parts. There appear to be no uses of 842 these encodings anywhere, so they are quite likely to change 843 incompatibly in future. 844 845 846 File: ctf-spec.info, Node: Slices, Next: Pointers typedefs and cvr-quals, Prev: Floating-point types, Up: The type section 847 848 2.3.6 Slices 849 ------------ 850 851 Slices, with kind 'CTF_K_SLICE', are an unusual CTF construct: they do 852 not directly correspond to any C type, but are a way to model other 853 types in a more convenient fashion for CTF generators. 854 855 A slice is like a pointer or other reference type in that they are 856 always represented by 'ctf_stype_t': but unlike pointers and other 857 reference types, they populate the 'ctt_size' field just like integral 858 types do, and come with an attached encoding and transform the encoding 859 of the underlying type. The underlying type is described in the 860 variable-length data, similarly to structure and union fields: see 861 below. Requests for the type size should also chase down to the 862 referenced type. 863 864 Slices are always nameless: 'ctt_name' is always zero for them. 865 866 (The 'libctf' API behaviour is unusual as well, and justifies the 867 existence of slices: 'ctf_type_kind' never returns 'CTF_K_SLICE' but 868 always the underlying type kind, so that consumers never need to know 869 about slices: they can tell if an apparent integer is actually a slice 870 if they need to by calling 'ctf_type_reference', which will uniquely 871 return the underlying integral type rather than erroring out with 872 'ECTF_NOTREF' if this is actually a slice. So slices act just like an 873 integer with an encoding, but more closely mirror DWARF and other 874 debugging information formats by allowing CTF file creators to represent 875 a bitfield as a slice of an underlying integral type.) 876 877 The vlen in the info word for a slice should be ignored and is always 878 zero. The variable-length data for a slice is a single 'ctf_slice_t': 879 880 typedef struct ctf_slice 881 { 882 uint32_t cts_type; 883 unsigned short cts_offset; 884 unsigned short cts_bits; 885 } ctf_slice_t; 886 887 Offset Name Description 888 ---------------------------------------------------------------------------------------- 889 0x0 'uint32_t cts_type' The type this slice is a slice of. Must be an 890 integral type (or a floating-point type, but 891 this nonsensical option will go away in v4.) 892 893 0x4 'unsigned short cts_offset' The offset of this integral type in bits from 894 the start of its enclosing structure field, 895 adjusted for endianness: 896 *note Structs and unions::. Identical 897 semantics to the 'CTF_INT_OFFSET' field: 898 *note Integer types::. This field is much too 899 long, because the maximum possible offset of 900 an integral type would easily fit in a char: 901 this field is bigger just for the sake of 902 alignment. This will change in v4. 903 904 0x6 'unsigned short cts_bits' The bit-width of this integral type. 905 Identical semantics to the 'CTF_INT_BITS' 906 field: *note Integer types::. As above, this 907 field is really too large and will shrink in 908 v4. 909 910 911 File: ctf-spec.info, Node: Pointers typedefs and cvr-quals, Next: Arrays, Prev: Slices, Up: The type section 912 913 2.3.7 Pointers, typedefs, and cvr-quals 914 --------------------------------------- 915 916 Pointers, 'typedef's, and 'const', 'volatile' and 'restrict' qualifiers 917 are represented identically except for their type kind (though they may 918 be treated differently by consuming libraries like 'libctf', since 919 pointers affect assignment-compatibility in ways cvr-quals do not, and 920 they may have different alignment requirements, etc). 921 922 All of these are represented by 'ctf_stype_t', have no variable data 923 at all, and populate 'ctt_type' with the type ID of the type they point 924 to. These types can stack: a 'CTF_K_RESTRICT' can point to a 925 'CTF_K_CONST' which can point to a 'CTF_K_POINTER' etc. 926 927 They are all unnamed: 'ctt_name' is 0. 928 929 The size of 'CTF_K_POINTER' is derived from the data model (*note 930 Data models::), i.e. in practice, from the target machine ABI, and is 931 not explicitly represented. The size of other kinds in this set should 932 be determined by chasing ctf_types as necessary until a 933 non-typedef/const/volatile/restrict is found, and using that. 934 935 936 File: ctf-spec.info, Node: Arrays, Next: Function pointers, Prev: Pointers typedefs and cvr-quals, Up: The type section 937 938 2.3.8 Arrays 939 ------------ 940 941 Arrays are encoded as types of kind 'CTF_K_ARRAY' in a 'ctf_stype_t'. 942 Both size and kind for arrays are zero. The variable-length data is a 943 'ctf_array_t': 'vlen' in the info word should be disregarded and is 944 always zero. 945 946 typedef struct ctf_array 947 { 948 uint32_t cta_contents; 949 uint32_t cta_index; 950 uint32_t cta_nelems; 951 } ctf_array_t; 952 953 Offset Name Description 954 ---------------------------------------------------------------------------------------- 955 0x0 'uint32_t cta_contents' The type of the array elements: a type ID. 956 957 0x4 'uint32_t cta_index' The type of the array index: a type ID of an 958 integral type. If this is a variable-length 959 array, the index type ID will be 0 (but the 960 actual index type of this array is probably 961 'int'). Probably redundant and may be 962 dropped in v4. 963 964 0x8 'uint32_t cta_nelems' The number of array elements. 0 for VLAs, 965 and also for the historical variety of VLA 966 which has explicit zero dimensions (which 967 will have a nonzero 'cta_index'.) 968 969 The size of an array can be computed by simple multiplication of the 970 size of the 'cta_contents' type by the 'cta_nelems'. 971 972 973 File: ctf-spec.info, Node: Function pointers, Next: Enums, Prev: Arrays, Up: The type section 974 975 2.3.9 Function pointers 976 ----------------------- 977 978 Function pointers are explicitly represented in the CTF type section by 979 a type of kind 'CTF_K_FUNCTION', always encoded with a 'ctf_stype_t'. 980 The 'ctt_type' is the function return type ID. The 'vlen' in the info 981 word is the number of arguments, each of which is a type ID, a 982 'uint32_t': if the last argument is 0, this is a varargs function and 983 the number of arguments is one less than indicated by the vlen. 984 985 If the number of arguments is odd, a single 'uint32_t' of padding is 986 inserted to maintain alignment. 987 988 989 File: ctf-spec.info, Node: Enums, Next: Structs and unions, Prev: Function pointers, Up: The type section 990 991 2.3.10 Enums 992 ------------ 993 994 Enumerated types are represented as types of kind 'CTF_K_ENUM' in a 995 'ctf_stype_t'. The 'ctt_size' is always the size of an int from the 996 data model (enum bitfields are implemented via slices). The 'vlen' is a 997 count of enumerations, each of which is represented by a 'ctf_enum_t' in 998 the vlen: 999 1000 typedef struct ctf_enum 1001 { 1002 uint32_t cte_name; 1003 int32_t cte_value; 1004 } ctf_enum_t; 1005 1006 Offset Name Description 1007 ------------------------------------------------------------------------ 1008 0x0 'uint32_t cte_name' Strtab offset of the enumeration name. 1009 Must not be 0. 1010 1011 0x4 'int32_t cte_value' The enumeration value. 1012 1013 1014 Enumeration values larger than 2^32 are not yet supported and are 1015 omitted from the enumeration. (v4 will lift this restriction by 1016 encoding the value differently.) 1017 1018 Forward declarations of enums are not implemented with this kind: 1019 *note Forward declarations::. 1020 1021 Enumerated type names, as usual in C, go into their own namespace, 1022 and do not conflict with non-enums, structs, or unions with the same 1023 name. 1024 1025 1026 File: ctf-spec.info, Node: Structs and unions, Next: Forward declarations, Prev: Enums, Up: The type section 1027 1028 2.3.11 Structs and unions 1029 ------------------------- 1030 1031 Structures and unions are represnted as types of kind 'CTF_K_STRUCT' and 1032 'CTF_K_UNION': their representation is otherwise identical, and it is 1033 perfectly allowed for "structs" to contain overlapping fields etc, so we 1034 will treat them together for the rest of this section. 1035 1036 They fill out 'ctt_size', and use 'ctf_type_t' in preference to 1037 'ctf_stype_t' if the structure size is greater than 'CTF_MAX_SIZE' 1038 (0xfffffffe). 1039 1040 The vlen for structures and unions is a count of structure fields, 1041 but the type used to represent a structure field (and thus the size of 1042 the variable-length array element representing the type) depends on the 1043 size of the structure: truly huge structures, greater than 1044 'CTF_LSTRUCT_THRESH' bytes in length, use a different type. 1045 ('CTF_LSTRUCT_THRESH' is 536870912, so such structures are vanishingly 1046 rare: in v4, this representation will change somewhat for greater 1047 compactness. It's inherited from v1, where the limits were much lower.) 1048 1049 Most structures can get away with using 'ctf_member_t': 1050 1051 typedef struct ctf_member_v2 1052 { 1053 uint32_t ctm_name; 1054 uint32_t ctm_offset; 1055 uint32_t ctm_type; 1056 } ctf_member_t; 1057 1058 Huge structures that are represented by 'ctf_type_t' rather than 1059 'ctf_stype_t' have to use 'ctf_lmember_t', which splits the offset as 1060 'ctf_type_t' splits the size: 1061 1062 typedef struct ctf_lmember_v2 1063 { 1064 uint32_t ctlm_name; 1065 uint32_t ctlm_offsethi; 1066 uint32_t ctlm_type; 1067 uint32_t ctlm_offsetlo; 1068 } ctf_lmember_t; 1069 1070 Here's what the fields of 'ctf_member' mean: 1071 1072 Offset Name Description 1073 --------------------------------------------------------------------------------------------------------- 1074 0x00 'uint32_t ctm_name' Strtab offset of the field name. 1075 1076 0x04 'uint32_t ctm_offset' The offset of this field _in bits_. (Usually, for bitfields, this is 1077 machine-word-aligned and the individual field has an offset in bits, 1078 but the format allows for the offset to be encoded in bits here.) 1079 1080 0x08 'uint32_t ctm_type' The type ID of the type of the field. 1081 1082 Here's what the fields of the very similar 'ctf_lmember' mean: 1083 1084 Offset Name Description 1085 ------------------------------------------------------------------------------------------------------------ 1086 0x00 'uint32_t ctlm_name' Strtab offset of the field name. 1087 1088 0x04 'uint32_t ctlm_offsethi' The high 32 bits of the offset of this field in bits. 1089 1090 0x08 'uint32_t ctlm_type' The type ID of the type of the field. 1091 1092 0x0c 'uint32_t ctlm_offsetlo' The low 32 bits of the offset of this field in bits. 1093 1094 Macros 'CTF_LMEM_OFFSET', 'CTF_OFFSET_TO_LMEMHI' and 1095 'CTF_OFFSET_TO_LMEMLO' serve to extract and install the values of the 1096 'ctlm_offset' fields, much as with the split size fields in 1097 'ctf_type_t'. 1098 1099 Unnamed structure and union fields are simply implemented by 1100 collapsing the unnamed field's members into the containing structure or 1101 union: this does mean that a structure containing an unnamed union can 1102 end up being a "structure" with multiple members at the same offset. (A 1103 future format revision may collapse 'CTF_K_STRUCT' and 'CTF_K_UNION' 1104 into the same kind and decide among them based on whether their members 1105 do in fact overlap.) 1106 1107 Structure and union type names, as usual in C, go into their own 1108 namespace, just as enum type names do. 1109 1110 Forward declarations of structures and unions are not implemented 1111 with this kind: *note Forward declarations::. 1112 1113 1114 File: ctf-spec.info, Node: Forward declarations, Prev: Structs and unions, Up: The type section 1115 1116 2.3.12 Forward declarations 1117 --------------------------- 1118 1119 When the compiler encounters a forward declaration of a struct, union, 1120 or enum, it emits a type of kind 'CTF_K_FORWARD'. If it later 1121 encounters a non- forward declaration of the same thing, it marks the 1122 forward as non-root-visible: before link time, therefore, 1123 non-root-visible forwards indicate that a non-forward is coming. 1124 1125 After link time, forwards are fused with their corresponding 1126 non-forwards by the deduplicator where possible. They are kept if there 1127 is no non-forward definition (maybe it's not visible from any TU at all) 1128 or if 'multiple' conflicting structures with the same name might match 1129 it. Otherwise, all other forwards are converted to structures, unions, 1130 or enums as appropriate, even across TUs if only one structure could 1131 correspond to the forward (after all, all types across all TUs land in 1132 the same dictionary unless they conflict, so promoting forwards to their 1133 concrete type seems most helpful). 1134 1135 A forward has a rather strange representation: it is encoded with a 1136 'ctf_stype_t' but the 'ctt_type' is populated not with a type (if it's a 1137 forward, we don't have an underlying type yet: if we did, we'd have 1138 promoted it and this wouldn't be a forward any more) but with the 'kind' 1139 of the forward. This means that we can distinguish forwards to structs, 1140 enums and unions reliably and ensure they land in the appropriate 1141 namespace even before the actual struct, union or enum is found. 1142 1143 1144 File: ctf-spec.info, Node: The symtypetab sections, Next: The variable section, Prev: The type section, Up: CTF dictionaries 1145 1146 2.4 The symtypetab sections 1147 =========================== 1148 1149 These are two very simple sections with identical formats, used by 1150 consumers to map from ELF function and data symbols directly to their 1151 types. So they are usually populated only in CTF sections that are 1152 embedded in ELF objects. 1153 1154 Their format is very simple: an array of type IDs. Which symbol each 1155 type ID corresponds to depends on whether the optional _index section_ 1156 associated with this symtypetab section has any content. 1157 1158 If the index section is nonempty, it is an array of 'uint32_t' string 1159 table offsets, each giving the name of the symbol whose type is at the 1160 same offset in the corresponding non-index section: users can look up 1161 symbols in such a table by name. The index section and corresponding 1162 symtypetab section is usually ASCIIbetically sorted (indicated by the 1163 'CTF_F_IDXSORTED' flag in the header): if it's sorted, it can be 1164 bsearched for a symbol name rather than having to use a slower linear 1165 search. 1166 1167 If the data object index section is empty, the entries in the data 1168 object and function info sections are associated 1:1 with ELF symbols of 1169 type 'STT_OBJECT' (for data object) or 'STT_FUNC' (for function info) 1170 with a nonzero value: the linker shuffles the symtypetab sections to 1171 correspond with the order of the symbols in the ELF file. Symbols with 1172 no name, undefined symbols and symbols named "'_START_'" and "'_END_'" 1173 are skipped and never appear in either section. Symbols that have no 1174 corresponding type are represented by type ID 0. The section may have 1175 fewer entries than the symbol table, in which case no later entries have 1176 associated types. This format is more compact than an indexed form if 1177 most entries have types (since there is no need to record any symbol 1178 names), but if the producer and consumer disagree even slightly about 1179 which symbols are omitted, the types of all further symbols will be 1180 wrong! 1181 1182 The compiler always emits indexed symtypetab tables, because there is 1183 no symbol table yet. The linker will always have to read them all in 1184 and always works through them from start to end, so there is no benefit 1185 having the compiler sort them either. The linker (actually, 'libctf''s 1186 linking machinery) will automatically sort unsorted indexed sections, 1187 and convert indexed sections that contain a lot of pads into the more 1188 compact, unindexed form. 1189 1190 If child dicts are in use, only symbols that use types actually 1191 mentioned in the child appear in the child's symtypetab: symbols that 1192 use only types in the parent appear in the parent's symtypetab instead. 1193 So the child's symtypetab will almost always be very sparse, and thus 1194 will usually use the indexed form even in fully linked objects. (It is, 1195 of course, impossible for symbols to exist that use types from multiple 1196 child dicts at once, since it's impossible to declare a function in C 1197 that uses types that are only visible in two different, disjoint 1198 translation units.) 1199 1200 1201 File: ctf-spec.info, Node: The variable section, Next: The label section, Prev: The symtypetab sections, Up: CTF dictionaries 1202 1203 2.5 The variable section 1204 ======================== 1205 1206 The variable section is a simple array mapping names (strtab entries) to 1207 type IDs, intended to provide a replacement for the data object section 1208 in dynamic situations in which there is no static ELF strtab but the 1209 consumer instead hands back names. The section is sorted into 1210 ASCIIbetical order by name for rapid lookup, like the CTF archive name 1211 table. 1212 1213 The section is an array of these structures: 1214 1215 typedef struct ctf_varent 1216 { 1217 uint32_t ctv_name; 1218 uint32_t ctv_type; 1219 } ctf_varent_t; 1220 1221 Offset Name Description 1222 ----------------------------------------------------------- 1223 0x00 'uint32_t ctv_name' Strtab offset of the name 1224 1225 0x04 'uint32_t ctv_type' Type ID of this type 1226 1227 There is no analogue of the function info section yet: v4 will 1228 probably drop this section in favour of a way to put both indexed (thus, 1229 named) and nonindexed symbols into the symtypetab sections at the same 1230 time. 1231 1232 1233 File: ctf-spec.info, Node: The label section, Next: The string section, Prev: The variable section, Up: CTF dictionaries 1234 1235 2.6 The label section 1236 ===================== 1237 1238 The label section is a currently-unused facility allowing the tiling of 1239 the type space with names taken from the strtab. The section is an 1240 array of these structures: 1241 1242 typedef struct ctf_lblent 1243 { 1244 uint32_t ctl_label; 1245 uint32_t ctl_type; 1246 } ctf_lblent_t; 1247 1248 Offset Name Description 1249 ------------------------------------------------------------- 1250 0x00 'uint32_t ctl_label' Strtab offset of the label 1251 1252 0x04 'uint32_t ctl_type' Type ID of the last type 1253 covered by this label 1254 1255 Semantics will be attached to labels soon, probably in v4 (the plan 1256 is to use them to allow multiple disjoint namespaces in a single CTF 1257 file, removing many uses of CTF archives, in particular in the '.ctf' 1258 section in ELF objects). 1259 1260 1261 File: ctf-spec.info, Node: The string section, Next: Data models, Prev: The label section, Up: CTF dictionaries 1262 1263 2.7 The string section 1264 ====================== 1265 1266 This section is a simple ELF-format strtab, starting with a zero byte 1267 (thus ensuring that the string with offset 0 is the null string, as 1268 assumed elsewhere in this spec). The strtab is usually ASCIIbetically 1269 sorted to somewhat improve compression efficiency. 1270 1271 Where the strtab is unusual is the _references_ to it. CTF has two 1272 string tables, the internal strtab and an external strtab associated 1273 with the CTF dictionary at open time: usually, this is the ELF dynamic 1274 strtab ('.dynstr') of a CTF dictionary embedded in an ELF file. We 1275 distinguish between these strtabs by the most significant bit, bit 31, 1276 of the 32-bit strtab references: if it is 0, the offset is in the 1277 internal strtab: if 1, the offset is in the external strtab. 1278 1279 There is a bug workaround in this area: in format v3 (the first 1280 version to have working support for external strtabs), the external 1281 strtab is '.strtab' unless the 'CTF_F_DYNSTR' flag is set on the 1282 dictionary (*note CTF file-wide flags::). Format v4 will introduce a 1283 header field that explicitly names the external strtab, making this flag 1284 unnecessary. 1285 1286 1287 File: ctf-spec.info, Node: Data models, Next: Limits of CTF, Prev: The string section, Up: CTF dictionaries 1288 1289 2.8 Data models 1290 =============== 1291 1292 The data model is a simple integer which indicates the ABI in use on 1293 this platform. Right now, it is very simple, distinguishing only 1294 between 32- and 64-bit types: a model of 1 indicates ILP32, 2 indicats 1295 LP64. The mapping from ABI integer to type sizes is hardwired into 1296 'libctf': currently, we use this to hardwire the size of pointers, 1297 function pointers, and enumerated types, 1298 1299 This is a very kludgy corner of CTF and will probably be replaced 1300 with explicit header fields to record this sort of thing in future. 1301 1302 1303 File: ctf-spec.info, Node: Limits of CTF, Prev: Data models, Up: CTF dictionaries 1304 1305 2.9 Limits of CTF 1306 ================= 1307 1308 The following limits are imposed by various aspects of CTF version 3: 1309 1310 'CTF_MAX_TYPE' 1311 Maximum type identifier (maximum number of types accessible with 1312 parent and child containers in use): 0xfffffffe 1313 'CTF_MAX_PTYPE' 1314 Maximum type identifier in a parent dictioanry: maximum number of 1315 types in any one dictionary: 0x7fffffff 1316 'CTF_MAX_NAME' 1317 Maximum offset into a string table: 0x7fffffff 1318 'CTF_MAX_VLEN' 1319 Maximum number of members in a struct, union, or enum: maximum 1320 number of function args: 0xffffff 1321 'CTF_MAX_SIZE' 1322 Maximum size of a 'ctf_stype_t' in bytes before we fall back to 1323 'ctf_type_t': 0xfffffffe bytes 1324 1325 Other maxima without associated macros: 1326 * Maximum value of an enumerated type: 2^32 1327 * Maximum size of an array element: 2^32 1328 1329 These maxima are generally considered to be too low, because C 1330 programs can and do exceed them: they will be lifted in format v4. 1331 1332 1333 File: ctf-spec.info, Node: Index, Prev: CTF dictionaries, Up: Top 1334 1335 Index 1336 ***** 1337 1338 [index] 1339 * Menu: 1340 1341 * alignment: CTF Preamble. (line 33) 1342 * archive, CTF archive: CTF archive. (line 6) 1343 * Arrays: Arrays. (line 6) 1344 * bool: Integer types. (line 6) 1345 * Bug workarounds, CTF_F_DYNSTR: The symtypetab sections. 1346 (line 6) 1347 * Bug workarounds, CTF_F_DYNSTR <1>: The string section. (line 19) 1348 * char: Integer types. (line 6) 1349 * Child range: Type indexes and type IDs. 1350 (line 6) 1351 * Complex, double: Floating-point types. (line 6) 1352 * Complex, float: Floating-point types. (line 6) 1353 * Complex, signed double: Floating-point types. (line 6) 1354 * Complex, signed float: Floating-point types. (line 6) 1355 * Complex, unsigned double: Floating-point types. (line 6) 1356 * Complex, unsigned float: Floating-point types. (line 6) 1357 * const: Pointers typedefs and cvr-quals. 1358 (line 6) 1359 * cta_contents: Arrays. (line 20) 1360 * cta_index: Arrays. (line 22) 1361 * cta_nelems: Arrays. (line 29) 1362 * cte_name: Enums. (line 21) 1363 * cte_value: Enums. (line 24) 1364 * CTF header: CTF header. (line 6) 1365 * CTF versions, versions: CTF Preamble. (line 46) 1366 * ctfa_ctfs: CTF archive. (line 76) 1367 * ctfa_magic: CTF archive. (line 63) 1368 * CTFA_MAGIC: CTF archive. (line 64) 1369 * ctfa_model: CTF archive. (line 66) 1370 * ctfa_names: CTF archive. (line 72) 1371 * ctfa_nfiles: CTF archive. (line 71) 1372 * ctf_archive_modent_t: CTF archive. (line 83) 1373 * ctf_archive_modent_t, ctf_offset: CTF archive. (line 88) 1374 * ctf_archive_modent_t, name_offset: CTF archive. (line 86) 1375 * ctf_array_t: Arrays. (line 18) 1376 * ctf_array_t, cta_contents: Arrays. (line 20) 1377 * ctf_array_t, cta_index: Arrays. (line 22) 1378 * ctf_array_t, cta_nelems: Arrays. (line 29) 1379 * CTF_CHAR: Integer types. (line 53) 1380 * ctf_enum_t: Enums. (line 18) 1381 * ctf_enum_t, cte_name: Enums. (line 21) 1382 * ctf_enum_t, cte_value: Enums. (line 24) 1383 * CTF_FP_BITS: Floating-point types. (line 28) 1384 * CTF_FP_CPLX: Floating-point types. (line 47) 1385 * CTF_FP_DCPLX: Floating-point types. (line 48) 1386 * CTF_FP_DIMAGRY: Floating-point types. (line 60) 1387 * CTF_FP_DINTRVL: Floating-point types. (line 54) 1388 * CTF_FP_DOUBLE: Floating-point types. (line 46) 1389 * CTF_FP_ENCODING: Floating-point types. (line 21) 1390 * CTF_FP_IMAGRY: Floating-point types. (line 58) 1391 * CTF_FP_INTRVL: Floating-point types. (line 52) 1392 * CTF_FP_LDCPLX: Floating-point types. (line 49) 1393 * CTF_FP_LDIMAGRY: Floating-point types. (line 62) 1394 * CTF_FP_LDINTRVL: Floating-point types. (line 56) 1395 * CTF_FP_LDOUBLE: Floating-point types. (line 50) 1396 * CTF_FP_OFFSET: Floating-point types. (line 25) 1397 * CTF_FP_SINGLE: Floating-point types. (line 45) 1398 * CTF_F_COMPRESS: CTF file-wide flags. (line 17) 1399 * CTF_F_DYNSTR: CTF file-wide flags. (line 21) 1400 * CTF_F_DYNSTR <1>: The symtypetab sections. 1401 (line 6) 1402 * CTF_F_DYNSTR <2>: The string section. (line 19) 1403 * CTF_F_IDXSORTED: CTF file-wide flags. (line 20) 1404 * CTF_F_IDXSORTED <1>: The symtypetab sections. 1405 (line 6) 1406 * CTF_F_NEWFUNCINFO: CTF file-wide flags. (line 19) 1407 * ctf_header_t: CTF header. (line 44) 1408 * ctf_header_t, cth_cuname: CTF header. (line 61) 1409 * ctf_header_t, cth_flags: CTF Preamble. (line 30) 1410 * ctf_header_t, cth_funcidxoff: CTF header. (line 82) 1411 * ctf_header_t, cth_funcoff: CTF header. (line 74) 1412 * ctf_header_t, cth_lbloff: CTF header. (line 66) 1413 * ctf_header_t, cth_magic: CTF Preamble. (line 24) 1414 * ctf_header_t, cth_objtidxoff: CTF header. (line 78) 1415 * ctf_header_t, cth_objtoff: CTF header. (line 70) 1416 * ctf_header_t, cth_parlabel: CTF header. (line 49) 1417 * ctf_header_t, cth_parname: CTF header. (line 55) 1418 * ctf_header_t, cth_preamble: CTF header. (line 47) 1419 * ctf_header_t, cth_strlen: CTF header. (line 98) 1420 * ctf_header_t, cth_stroff: CTF header. (line 95) 1421 * ctf_header_t, cth_typeoff: CTF header. (line 91) 1422 * ctf_header_t, cth_varoff: CTF header. (line 87) 1423 * ctf_header_t, cth_version: CTF Preamble. (line 28) 1424 * ctf_id_t: Type indexes and type IDs. 1425 (line 6) 1426 * CTF_INT_BITS: Integer types. (line 28) 1427 * CTF_INT_BOOL: Integer types. (line 57) 1428 * CTF_INT_CHAR: Integer types. (line 53) 1429 * CTF_INT_DATA: Integer types. (line 34) 1430 * CTF_INT_DATA <1>: Floating-point types. (line 36) 1431 * CTF_INT_ENCODING: Integer types. (line 20) 1432 * CTF_INT_OFFSET: Integer types. (line 25) 1433 * CTF_INT_SIGNED: Integer types. (line 49) 1434 * CTF_K_CONST: Pointers typedefs and cvr-quals. 1435 (line 6) 1436 * CTF_K_ENUM: Enums. (line 6) 1437 * CTF_K_FLOAT: Floating-point types. (line 6) 1438 * CTF_K_FORWARD: Forward declarations. (line 6) 1439 * CTF_K_INTEGER: Integer types. (line 6) 1440 * CTF_K_POINTER: Pointers typedefs and cvr-quals. 1441 (line 6) 1442 * CTF_K_RESTRICT: Pointers typedefs and cvr-quals. 1443 (line 6) 1444 * CTF_K_SLICE: Slices. (line 6) 1445 * CTF_K_STRUCT: Structs and unions. (line 6) 1446 * CTF_K_TYPEDEF: Pointers typedefs and cvr-quals. 1447 (line 6) 1448 * CTF_K_UNION: Structs and unions. (line 6) 1449 * CTF_K_UNKNOWN: Type kinds. (line 31) 1450 * CTF_K_VOLATILE: Pointers typedefs and cvr-quals. 1451 (line 6) 1452 * ctf_lblent_t: The label section. (line 16) 1453 * ctf_lblent_t, ctl_label: The label section. (line 19) 1454 * ctf_lblent_t, ctl_type: The label section. (line 20) 1455 * ctf_lmember_t: Structs and unions. (line 59) 1456 * ctf_lmember_t, ctlm_name: Structs and unions. (line 61) 1457 * ctf_lmember_t, ctlm_offsethi: Structs and unions. (line 64) 1458 * ctf_lmember_t, ctlm_offsetlo: Structs and unions. (line 68) 1459 * CTF_LSIZE_SENT: The type section. (line 49) 1460 * CTF_LSTRUCT_THRESH: Structs and unions. (line 23) 1461 * CTF_MAGIC: CTF Preamble. (line 25) 1462 * CTF_MAX_LSIZE: Structs and unions. (line 13) 1463 * ctf_member_t: Structs and unions. (line 47) 1464 * ctf_member_t, ctlm_type: Structs and unions. (line 65) 1465 * ctf_member_t, ctm_name: Structs and unions. (line 49) 1466 * ctf_member_t, ctm_offset: Structs and unions. (line 52) 1467 * ctf_member_t, ctm_type: Structs and unions. (line 55) 1468 * ctf_offset: CTF archive. (line 88) 1469 * ctf_preamble_t: CTF Preamble. (line 22) 1470 * ctf_preamble_t, ctp_flags: CTF Preamble. (line 30) 1471 * ctf_preamble_t, ctp_magic: CTF Preamble. (line 24) 1472 * ctf_preamble_t, ctp_version: CTF Preamble. (line 28) 1473 * CTF_SIZE_TO_LSIZE_HI: The type section. (line 79) 1474 * CTF_SIZE_TO_LSIZE_LO: The type section. (line 83) 1475 * ctf_slice_t: Slices. (line 42) 1476 * ctf_slice_t, cts_bits: Slices. (line 59) 1477 * ctf_slice_t, cts_offset: Slices. (line 49) 1478 * ctf_slice_t, cts_type: Slices. (line 44) 1479 * ctf_stype_t: The type section. (line 53) 1480 * ctf_stype_t, ctt_info: The type section. (line 57) 1481 * ctf_stype_t, ctt_size: The type section. (line 62) 1482 * ctf_stype_t, ctt_type: The type section. (line 67) 1483 * CTF_TYPE_INFO: The info word. (line 45) 1484 * CTF_TYPE_LSIZE: The type section. (line 79) 1485 * ctf_type_t: The type section. (line 53) 1486 * ctf_type_t, ctt_info: The type section. (line 57) 1487 * ctf_type_t, ctt_lsizehi: The type section. (line 76) 1488 * ctf_type_t, ctt_lsizelo: The type section. (line 82) 1489 * ctf_type_t, ctt_size: The type section. (line 62) 1490 * CTF_V2_INDEX_TO_TYPE: Type indexes and type IDs. 1491 (line 58) 1492 * CTF_V2_INFO_ISROOT: The info word. (line 45) 1493 * CTF_V2_INFO_KIND: The info word. (line 45) 1494 * CTF_V2_INFO_VLEN: The info word. (line 45) 1495 * CTF_V2_TYPE_ISCHILD: Type indexes and type IDs. 1496 (line 58) 1497 * CTF_V2_TYPE_ISPARENT: Type indexes and type IDs. 1498 (line 58) 1499 * CTF_V2_TYPE_TO_INDEX: Type indexes and type IDs. 1500 (line 58) 1501 * ctf_varent_t: The variable section. (line 21) 1502 * ctf_varent_t, ctv_name: The variable section. (line 24) 1503 * ctf_varent_t, ctv_type: The variable section. (line 26) 1504 * CTF_VERSION_3: CTF Preamble. (line 46) 1505 * cth_cuname: CTF header. (line 61) 1506 * cth_flags: CTF Preamble. (line 30) 1507 * cth_funcidxoff: CTF header. (line 82) 1508 * cth_funcoff: CTF header. (line 74) 1509 * cth_lbloff: CTF header. (line 66) 1510 * cth_magic: CTF Preamble. (line 24) 1511 * cth_objtidxoff: CTF header. (line 78) 1512 * cth_objtoff: CTF header. (line 70) 1513 * cth_parlabel: CTF header. (line 49) 1514 * cth_parname: CTF header. (line 55) 1515 * cth_preamble: CTF header. (line 47) 1516 * cth_strlen: CTF header. (line 98) 1517 * cth_stroff: CTF header. (line 95) 1518 * cth_typeoff: CTF header. (line 91) 1519 * cth_varoff: CTF header. (line 87) 1520 * cth_version: CTF Preamble. (line 28) 1521 * ctlm_name: Structs and unions. (line 61) 1522 * ctlm_offsethi: Structs and unions. (line 64) 1523 * ctlm_offsetlo: Structs and unions. (line 68) 1524 * ctl_label: The label section. (line 19) 1525 * ctl_type: The label section. (line 20) 1526 * ctm_name: Structs and unions. (line 49) 1527 * ctm_offset: Structs and unions. (line 52) 1528 * ctm_type: Structs and unions. (line 55) 1529 * ctm_type <1>: Structs and unions. (line 65) 1530 * ctp_flags: CTF Preamble. (line 30) 1531 * ctp_flags <1>: CTF Preamble. (line 58) 1532 * ctp_magic: CTF Preamble. (line 24) 1533 * ctp_version: CTF Preamble. (line 28) 1534 * cts_bits: Slices. (line 59) 1535 * cts_offset: Slices. (line 49) 1536 * cts_type: Slices. (line 44) 1537 * ctt_info: The type section. (line 57) 1538 * ctt_lsizehi: The type section. (line 76) 1539 * ctt_lsizelo: The type section. (line 82) 1540 * ctt_name: The type section. (line 55) 1541 * ctt_size: The type section. (line 62) 1542 * ctt_type: The type section. (line 67) 1543 * ctv_name: The variable section. (line 24) 1544 * ctv_type: The variable section. (line 26) 1545 * cvr-quals: Pointers typedefs and cvr-quals. 1546 (line 6) 1547 * Data models: Data models. (line 6) 1548 * Data object index section: The symtypetab sections. 1549 (line 6) 1550 * Data object section: The symtypetab sections. 1551 (line 6) 1552 * dictionary, CTF dictionary: CTF dictionaries. (line 6) 1553 * double: Floating-point types. (line 6) 1554 * endianness: CTF Preamble. (line 37) 1555 * enum: Enums. (line 6) 1556 * enum <1>: Forward declarations. (line 6) 1557 * Enums: Enums. (line 6) 1558 * float: Floating-point types. (line 6) 1559 * Floating-point types: Floating-point types. (line 6) 1560 * Forwards: Forward declarations. (line 6) 1561 * Function info index section: The symtypetab sections. 1562 (line 6) 1563 * Function info section: The symtypetab sections. 1564 (line 6) 1565 * Function pointers: Function pointers. (line 6) 1566 * int: Integer types. (line 6) 1567 * Integer types: Integer types. (line 6) 1568 * Label section: The label section. (line 6) 1569 * libctf, effect of slices: Slices. (line 30) 1570 * Limits: Limits of CTF. (line 6) 1571 * long: Integer types. (line 6) 1572 * long long: Integer types. (line 6) 1573 * name_offset: CTF archive. (line 86) 1574 * Overview: Overview. (line 6) 1575 * Parent range: Type indexes and type IDs. 1576 (line 6) 1577 * Pointers: Pointers typedefs and cvr-quals. 1578 (line 6) 1579 * Pointers, to functions: Function pointers. (line 6) 1580 * restrict: Pointers typedefs and cvr-quals. 1581 (line 6) 1582 * Sections, data object: The symtypetab sections. 1583 (line 6) 1584 * Sections, data object index: The symtypetab sections. 1585 (line 6) 1586 * Sections, function info: The symtypetab sections. 1587 (line 6) 1588 * Sections, function info index: The symtypetab sections. 1589 (line 6) 1590 * Sections, header: CTF header. (line 6) 1591 * Sections, label: The label section. (line 6) 1592 * Sections, string: The string section. (line 6) 1593 * Sections, symtypetab: The symtypetab sections. 1594 (line 6) 1595 * Sections, type: The type section. (line 6) 1596 * Sections, variable: The variable section. (line 6) 1597 * short: Integer types. (line 6) 1598 * signed char: Integer types. (line 6) 1599 * signed double: Floating-point types. (line 6) 1600 * signed float: Floating-point types. (line 6) 1601 * signed int: Integer types. (line 6) 1602 * signed long: Integer types. (line 6) 1603 * signed long long: Integer types. (line 6) 1604 * signed short: Integer types. (line 6) 1605 * Slices: Slices. (line 6) 1606 * Slices, effect on ctf_type_kind: Slices. (line 30) 1607 * Slices, effect on ctf_type_reference: Slices. (line 30) 1608 * String section: The string section. (line 6) 1609 * struct: Structs and unions. (line 6) 1610 * struct <1>: Forward declarations. (line 6) 1611 * struct ctf_archive: CTF archive. (line 61) 1612 * struct ctf_archive, ctfa_ctfs: CTF archive. (line 76) 1613 * struct ctf_archive, ctfa_magic: CTF archive. (line 63) 1614 * struct ctf_archive, ctfa_model: CTF archive. (line 66) 1615 * struct ctf_archive, ctfa_names: CTF archive. (line 72) 1616 * struct ctf_archive, ctfa_nfiles: CTF archive. (line 71) 1617 * struct ctf_archive_modent: CTF archive. (line 83) 1618 * struct ctf_archive_modent, ctf_offset: CTF archive. (line 88) 1619 * struct ctf_archive_modent, name_offset: CTF archive. (line 86) 1620 * struct ctf_array: Arrays. (line 18) 1621 * struct ctf_array, cta_contents: Arrays. (line 20) 1622 * struct ctf_array, cta_index: Arrays. (line 22) 1623 * struct ctf_array, cta_nelems: Arrays. (line 29) 1624 * struct ctf_enum: Enums. (line 18) 1625 * struct ctf_enum, cte_name: Enums. (line 21) 1626 * struct ctf_enum, cte_value: Enums. (line 24) 1627 * struct ctf_header: CTF header. (line 44) 1628 * struct ctf_header, cth_cuname: CTF header. (line 61) 1629 * struct ctf_header, cth_flags: CTF Preamble. (line 30) 1630 * struct ctf_header, cth_funcidxoff: CTF header. (line 82) 1631 * struct ctf_header, cth_funcoff: CTF header. (line 74) 1632 * struct ctf_header, cth_lbloff: CTF header. (line 66) 1633 * struct ctf_header, cth_magic: CTF Preamble. (line 24) 1634 * struct ctf_header, cth_objtidxoff: CTF header. (line 78) 1635 * struct ctf_header, cth_objtoff: CTF header. (line 70) 1636 * struct ctf_header, cth_parlabel: CTF header. (line 49) 1637 * struct ctf_header, cth_parname: CTF header. (line 55) 1638 * struct ctf_header, cth_preamble: CTF header. (line 47) 1639 * struct ctf_header, cth_strlen: CTF header. (line 98) 1640 * struct ctf_header, cth_stroff: CTF header. (line 95) 1641 * struct ctf_header, cth_typeoff: CTF header. (line 91) 1642 * struct ctf_header, cth_varoff: CTF header. (line 87) 1643 * struct ctf_header, cth_version: CTF Preamble. (line 28) 1644 * struct ctf_lblent: The label section. (line 16) 1645 * struct ctf_lblent, ctl_label: The label section. (line 19) 1646 * struct ctf_lblent, ctl_type: The label section. (line 20) 1647 * struct ctf_lmember_v2: Structs and unions. (line 59) 1648 * struct ctf_lmember_v2, ctlm_name: Structs and unions. (line 61) 1649 * struct ctf_lmember_v2, ctlm_offsethi: Structs and unions. (line 64) 1650 * struct ctf_lmember_v2, ctlm_offsetlo: Structs and unions. (line 68) 1651 * struct ctf_lmember_v2, ctlm_type: Structs and unions. (line 65) 1652 * struct ctf_member_v2: Structs and unions. (line 47) 1653 * struct ctf_member_v2, ctm_name: Structs and unions. (line 49) 1654 * struct ctf_member_v2, ctm_offset: Structs and unions. (line 52) 1655 * struct ctf_member_v2, ctm_type: Structs and unions. (line 55) 1656 * struct ctf_preamble: CTF Preamble. (line 22) 1657 * struct ctf_preamble, ctp_flags: CTF Preamble. (line 30) 1658 * struct ctf_preamble, ctp_magic: CTF Preamble. (line 24) 1659 * struct ctf_preamble, ctp_version: CTF Preamble. (line 28) 1660 * struct ctf_slice: Slices. (line 42) 1661 * struct ctf_slice, cts_bits: Slices. (line 59) 1662 * struct ctf_slice, cts_offset: Slices. (line 49) 1663 * struct ctf_slice, cts_type: Slices. (line 44) 1664 * struct ctf_stype: The type section. (line 53) 1665 * struct ctf_stype, ctt_info: The type section. (line 57) 1666 * struct ctf_stype, ctt_size: The type section. (line 62) 1667 * struct ctf_stype, ctt_type: The type section. (line 67) 1668 * struct ctf_type: The type section. (line 53) 1669 * struct ctf_type, ctt_info: The type section. (line 57) 1670 * struct ctf_type, ctt_lsizehi: The type section. (line 76) 1671 * struct ctf_type, ctt_lsizelo: The type section. (line 82) 1672 * struct ctf_type, ctt_size: The type section. (line 62) 1673 * struct ctf_varent: The variable section. (line 21) 1674 * struct ctf_varent, ctv_name: The variable section. (line 24) 1675 * struct ctf_varent, ctv_type: The variable section. (line 26) 1676 * Structures: Structs and unions. (line 6) 1677 * Symtypetab section: The symtypetab sections. 1678 (line 6) 1679 * Type IDs: Type indexes and type IDs. 1680 (line 6) 1681 * Type IDs, ranges: Type indexes and type IDs. 1682 (line 6) 1683 * Type indexes: Type indexes and type IDs. 1684 (line 6) 1685 * Type kinds: Type kinds. (line 6) 1686 * Type section: The type section. (line 6) 1687 * Type, IDs of: Type indexes and type IDs. 1688 (line 6) 1689 * Type, indexes of: Type indexes and type IDs. 1690 (line 6) 1691 * Type, kinds of: Type kinds. (line 6) 1692 * typedef: Pointers typedefs and cvr-quals. 1693 (line 6) 1694 * Typedefs: Pointers typedefs and cvr-quals. 1695 (line 6) 1696 * Types, floating-point: Floating-point types. (line 6) 1697 * Types, integer: Integer types. (line 6) 1698 * Types, slices of integral: Slices. (line 6) 1699 * union: Structs and unions. (line 6) 1700 * union <1>: Forward declarations. (line 6) 1701 * Unions: Structs and unions. (line 6) 1702 * unsigned char: Integer types. (line 6) 1703 * unsigned double: Floating-point types. (line 6) 1704 * unsigned float: Floating-point types. (line 6) 1705 * unsigned int: Integer types. (line 6) 1706 * unsigned long: Integer types. (line 6) 1707 * unsigned long long: Integer types. (line 6) 1708 * unsigned short: Integer types. (line 6) 1709 * Unused bits: Floating-point types. (line 52) 1710 * Unused bits <1>: Floating-point types. (line 54) 1711 * Unused bits <2>: Floating-point types. (line 56) 1712 * Unused bits <3>: Floating-point types. (line 58) 1713 * Unused bits <4>: Floating-point types. (line 60) 1714 * Unused bits <5>: Floating-point types. (line 62) 1715 * Variable section: The variable section. (line 6) 1716 * volatile: Pointers typedefs and cvr-quals. 1717 (line 6) 1718 1719 1720 1721 Tag Table: 1722 Node: Top548 1723 Node: Overview878 1724 Node: CTF archive4165 1725 Node: CTF dictionaries8791 1726 Node: CTF Preamble9208 1727 Node: CTF file-wide flags11818 1728 Node: CTF header13276 1729 Node: The type section19200 1730 Node: The info word23865 1731 Node: Type indexes and type IDs26395 1732 Node: Type kinds29763 1733 Node: Integer types33056 1734 Node: Floating-point types36604 1735 Node: Slices40629 1736 Node: Pointers typedefs and cvr-quals44133 1737 Node: Arrays45304 1738 Node: Function pointers47035 1739 Node: Enums47700 1740 Node: Structs and unions48982 1741 Node: Forward declarations52839 1742 Node: The symtypetab sections54418 1743 Node: The variable section57496 1744 Node: The label section58634 1745 Node: The string section59609 1746 Node: Data models60871 1747 Node: Limits of CTF61540 1748 Node: Index62585 1749 1750 End Tag Table 1751 1752 1753 Local Variables: 1754 coding: utf-8 1755 End: 1756
Indexes created Sat May 02 00:23:24 UTC 2026