1This is ctf-spec.info, produced by makeinfo version 6.8 from 2ctf-spec.texi. 3 4Copyright (C) 2021-2022 Free Software Foundation, Inc. 5 6 Permission is granted to copy, distribute and/or modify this document 7under the terms of the GNU General Public License, Version 3 or any 8later version published by the Free Software Foundation. A copy of the 9license is included in the section entitled "GNU General Public 10License". 11 12INFO-DIR-SECTION Software development 13START-INFO-DIR-ENTRY 14* CTF: (ctf-spec). The CTF file format. 15END-INFO-DIR-ENTRY 16 17 18File: ctf-spec.info, Node: Top, Next: Overview, Up: (dir) 19 20The CTF file format 21******************* 22 23This manual describes version 3 of the CTF file format, which is 24intended to model the C type system in a fashion that C programs can 25consume at runtime. 26 27* Menu: 28 29* Overview:: 30* CTF archive:: 31* CTF dictionaries:: 32* Index:: 33 34 35File: ctf-spec.info, Node: Overview, Next: CTF archive, Prev: Top, Up: Top 36 37Overview 38******** 39 40The CTF file format compactly describes C types and the association 41between function and data symbols and types: if embedded in ELF objects, 42it can exploit the ELF string table to reduce duplication further. 43There is no real concept of namespacing: only top-level types are 44described, not types scoped to within single functions. 45 46 CTF dictionaries can be "children" of other dictionaries, in a 47one-level hierarchy: child dictionaries can refer to types in the 48parent, but the opposite is not sensible (since if you refer to a child 49type in the parent, the actual type you cited would vary depending on 50what child was attached). This parent/child definition is recorded in 51the child, but only as a recommendation: users of the API have to attach 52parents to children explicitly, and can choose to attach a child to any 53parent they like, or to none, though doing so might lead to unpleasant 54consequences like dangling references to types. *Note Type indexes and 55type IDs::. Type lookups in child dicts that are not associated with a 56parent at all will fail with 'ECTF_NOPARENT' if a parent type was 57needed. 58 59 The associated API to generate, merge together, and query this file 60format will be described in the accompanying 'libctf' manual once it is 61written. There is no API to modify dictionaries once they've been 62written out: CTF is a write-once file format. (However, it is always 63possible to dynamically create a new child dictionary on the fly and 64attach 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 69of the source code still uses the old term.) 70 71 The archive file format is a very simple mmappable archive used to 72group multiple dictionaries together into groups: it is expected to 73slowly go away and be replaced by other mechanisms, but right now it is 74an important part of the file format, used to group dictionaries 75containing types with conflicting definitions in different TUs with the 76overarching dictionary used to store all other types. (Even when 77archives go away, the 'libctf' API used to access them will remain, and 78access the other mechanisms that replace it instead.) 79 80 The CTF dictionary consists of a "preamble", which does not vary 81between versions of the CTF file format, and a "header" and some number 82of "sections", which can vary between versions. 83 84 The rest of this specification describes the format of these 85sections, first for the latest version of CTF, then for all earlier 86versions supported by 'libctf': the earlier versions are defined in 87terms of their differences from the next later one. We describe each 88part of the format first by reproducing the C structure which defines 89that part, then describing it at greater length in terms of file 90offsets. 91 92 The description of the file format ends with a description of 93relevant limits that apply to it. These limits can vary between file 94format versions. 95 96 This document is quite young, so for now the C code in 'ctf.h' should 97be presumed correct when this document conflicts with it. 98 99 100File: ctf-spec.info, Node: CTF archive, Next: CTF dictionaries, Prev: Overview, Up: Top 101 1021 CTF archives 103************** 104 105The CTF archive format maps names to CTF dictionaries. The names may 106contain any character other than \0, but for now archives containing 107slashes in the names may not extract correctly. It is possible to 108insert multiple members with the same name, but these are quite hard to 109access reliably (you have to iterate through all the members rather than 110opening by name) so this is not recommended. 111 112 CTF archives are not themselves compressed: the constituent 113components, CTF dictionaries, can be compressed. (*Note CTF header::). 114 115 CTF archives usually contain a collection of related dictionaries, 116one parent and many children of that parent. CTF archives can have a 117member with a "default name", '.ctf' (which can be represented as 'NULL' 118in the API). If present, this member is usually the parent of all the 119children, but it is possible for CTF producers to emit parents with 120different names if they wish (usually for backward- compatibility 121purposes). 122 123 '.ctf' sections in ELF objects consist of a single CTF dictionary 124rather than an archive of dictionaries if and only if the section 125contains no types with identical names but conflicting definitions: if 126two conflicting definitions exist, the deduplicator will place the type 127most commonly referred to by other types in the parent and will place 128the other type in a child named after the translation unit it is found 129in, and will emit a CTF archive containing both dictionaries instead of 130a raw dictionary. All types that refer to such conflicting types are 131also placed in the per-translation-unit child. 132 133 The definition of an archive in 'ctf.h' is as follows: 134 135struct 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 144typedef 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 152that things that are not really archives can be made to appear as if 153they were.) 154 155 All the above items are always in little-endian byte order, 156regardless of the machine endianness. 157 158 The archive header has the following fields: 159 160Offset Name Description 161------------------------------------------------------------------------------------------ 1620x00 'uint64_t ctfa_magic' The magic number for archives, 'CTFA_MAGIC': 163 0x8b47f2a4d7623eeb. 164 1650x08 '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 1690x10 'uint64_t ctfa_nfiles' The number of CTF dictionaries in this archive. 170 1710x18 '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 1750x20 '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 182Offset Name Description 183--------------------------------------------------------------------------------- 1840x00 'uint64_t name_offset' Offset of this name, in bytes from the start 185 of the archive. 186 1870x08 '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 195dictionaries: these are pointed to by the structures above. The name 196table is a simple strtab which is not required to be sorted; the 197dictionary array is described above in the entry for 'ctfa_ctfs'. 198 199 The relative order of these various parts is not defined, except that 200the header naturally always comes first. 201 202 203File: ctf-spec.info, Node: CTF dictionaries, Next: Index, Prev: CTF archive, Up: Top 204 2052 CTF dictionaries 206****************** 207 208CTF dictionaries consist of a header, starting with a premable, and a 209number 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 224File: ctf-spec.info, Node: CTF Preamble, Next: CTF header, Up: CTF dictionaries 225 2262.1 CTF Preamble 227================ 228 229The preamble is the only part of the CTF dictionary whose format cannot 230vary between versions. It is never compressed. It is correspondingly 231simple: 232 233typedef 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' 241and 'cth_flags' to make the fields of the 'ctf_preamble_t' appear to be 242part of the 'ctf_header_t', so consuming programs rarely need to 243consider the existence of the preamble as a separate structure. 244 245Offset Name Description 246------------------------------------------------------------------------------- 2470x00 'unsigned short ctp_magic' The magic number for CTF 248 dictionaries, 'CTF_MAGIC': 0xdff2. 249 2500x02 'unsigned char ctp_version' The version number of this CTF 251 dictionary. 252 2530x03 '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 257otherwise specified. (This restriction will be lifted in later 258versions.) 259 260 CTF dictionaries are stored in the native endianness of the system 261that generates them: the consumer (e.g., 'libctf') can detect whether to 262endian-flip a CTF dictionary by inspecting the 'ctp_magic'. (If it 263appears 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' 267can read all of them: 268 269Version 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 287File: ctf-spec.info, Node: CTF file-wide flags, Up: CTF Preamble 288 2892.1.1 CTF file-wide flags 290------------------------- 291 292The preamble contains bitflags in its 'ctp_flags' field that describe 293various file-wide properties. Some of the flags are valid only for 294particular file-format versions, which means the flags can be used to 295fix file-format bugs. Consumers that see unknown flags should 296accordingly assume that the dictionary is not comprehensible, and refuse 297to open them. 298 299 The following flags are currently defined. Many are bug workarounds, 300valid only in CTFv3, and will not be valid in any future versions: the 301same values may be reused for other flags in v4+. 302 303Flag 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 313and data object sections. *Note The symtypetab sections::. 314 315 Further flags (and further compression methods) wil be added in 316future. 317 318 319File: ctf-spec.info, Node: CTF header, Next: The type section, Prev: CTF Preamble, Up: CTF dictionaries 320 3212.2 CTF header 322============== 323 324The CTF header is the first part of a CTF dictionary, including the 325preamble. All parts of it other than the preamble (*note CTF 326Preamble::) can vary between CTF file versions and are never compressed. 327It contains things that apply to the dictionary as a whole, and a table 328of the sections into which the rest of the dictionary is divided. The 329sections tile the file: each section runs from the offset given until 330the start of the next section. Only the last section cannot follow this 331rule, so the header has a length for it instead. 332 333 All section offsets, here and in the rest of the CTF file, are 334relative to the _end_ of the header. (This is annoyingly different to 335how offsets in CTF archives are handled.) 336 337 This is the first structure to include offsets into the string table, 338which are not straight references because CTF dictionaries can include 339references into the ELF string table to save space, as well as into the 340string table internal to the CTF dictionary. *Note The string section:: 341for more on these. Offset 0 is always the null string. 342 343typedef 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 362Offset Name Description 363----------------------------------------------------------------------------------------------- 3640x00 'ctf_preamble_t cth_preamble' The preamble (conceptually embedded in the header). 365 *Note CTF Preamble:: 366 3670x04 '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 3730x08 '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 3790x1c '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 3840x10 '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 3880x14 '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 3920x18 '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 3960x1c '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 4000x20 '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 4050x24 'uint32_t cth_varoff' The offset of the variable section, which maps 406 string names to types. 407 *Note The variable section::. 408 4090x28 '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 4130x2c 'uint32_t cth_stroff' The offset of the string section. 414 *Note The string section::. 415 4160x30 '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' 422is set in the preamble's 'ctp_flags'. 423 424 425File: ctf-spec.info, Node: The type section, Next: The symtypetab sections, Prev: CTF header, Up: CTF dictionaries 426 4272.3 The type section 428==================== 429 430This section is the most important section in CTF, describing all the 431top-level types in the program. It consists of an array of type 432structures, each of which describes a type of some "kind": each kind of 433type has some amount of variable-length data associated with it (some 434kinds have none). The amount of variable-length data associated with a 435given type can be determined by inspecting the type, so the reading code 436can walk through the types in sequence at opening time. 437 438 Each type structure is one of a set of overlapping structures in a 439discriminated union of sorts: the variable-length data for each type 440immediately follows the type's type structure. Here's the largest of 441the overlapping structures, which is only needed for huge types and so 442is very rarely seen: 443 444typedef 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 460typedef 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 473is described by a 'ctf_type_t': otherwise, a 'ctf_stype_t'. 474 475 Here's what the fields mean: 476 477Offset Name Description 478----------------------------------------------------------------------------------------------------- 4790x00 'uint32_t ctt_name' Strtab offset of the type name, if any (0 if none). 480 4810x04 '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 4860x08 '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 4910x08 '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 4990x0c ('ctf_type_t' 'uint32_t ctt_lsizehi' The high 32 bits of the size of a very large type. 500only) 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 5050x10 ('ctf_type_t' 'uint32_t ctt_lsizelo' The low 32 bits of the size of a very large type. 506only) '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 510exactly a type ID is and how you determine it. (Information on the 511various 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 530File: ctf-spec.info, Node: The info word, Next: Type indexes and type IDs, Up: The type section 531 5322.3.1 The info word, ctt_info 533----------------------------- 534 535The info word is a bitfield split into three parts. From MSB to LSB: 536 537Bit offset Name Description 538------------------------------------------------------------------------------------------ 53926-31 'kind' Type kind: *note Type kinds::. 540 54125 'isroot' 1 if this type is visible to name lookup 542 5430-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 551whether types with names (nonzero 'ctt_name') are visible to name 552lookup: if zero, this type is considered a "non-root type" and you can't 553look it up by name at all. Multiple types with the same name in the 554same C namespace (struct, union, enum, other) can exist in a single 555dictionary, but only one of them may have a nonzero value for 'isroot'. 556'libctf' validates this at open time and refuses to open dictionaries 557that violate this constraint. 558 559 Historically, this feature was introduced for the encoding of 560bitfields (*note Integer types::): for instance, int bitfields will all 561be named 'int' with different widths or offsets, but only the full-width 562one at offset zero is wanted when you look up the type named 'int'. 563With the introduction of slices (*note Slices::) as a more general 564bitfield encoding mechanism, this is less important, but we still use 565non-root types to handle conflicts if the linker API is used to fuse 566multiple translation units into one dictionary and those translation 567units contain types with the same name and conflicting definitions. (We 568do not discuss this further here, because the linker never does this: 569only specialized type mergers do, like that used for the Linux kernel. 570The 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' 574and 'CTF_V2_INFO_VLEN' pick it apart again. 575 576 577File: ctf-spec.info, Node: Type indexes and type IDs, Next: Type kinds, Prev: The info word, Up: The type section 578 5792.3.2 Type indexes and type IDs 580------------------------------- 581 582Types are referred to within the CTF file via "type IDs". A type ID is 583a number from 0 to 2^32, from a space divided in half. Types 2^31-1 and 584below are in the "parent range": these IDs are used for dictionaries 585that have not had any other dictionary 'ctf_import'ed into it as a 586parent. Both completely standalone dictionaries and parent dictionaries 587with children hanging off them have types in this range. Types 2^31 and 588above are in the "child range": only types in child dictionaries are in 589this range. 590 591 These IDs appear in 'ctf_type_t.ctt_type' (*note The type section::), 592but the types themselves have no visible ID: quite intentionally, 593because adding an ID uses space, and every ID is different so they don't 594compress well. The IDs are implicit: at open time, the consumer walks 595through the entire type section and counts the types in the type 596section. The type section is an array of variable-length elements, so 597each entry could be considered as having an index, starting from 1. We 598count 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 602dictionary if this dictionary has one associated with it; lookups of 603types with IDs in the child space error out if the dictionary does not 604have a parent, and otherwise convert the ID into an index by shaving off 605the top bit and look up the index in the child. 606 607 These properties mean that the same dictionary can be used as a 608parent of child dictionaries and can also be used directly with no 609children at all, but a dictionary created as a child dictionary must 610always be associated with a parent -- usually, the same parent -- 611because its references to its own types have the high bit turned on and 612this is only flipped off again if this is a child dictionary. (This is 613not a problem, because if you _don't_ associate the child with a parent, 614any references within it to its parent types will fail, and there are 615almost 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 618distinction between type IDs and type indexes: if you mix them up, 619everything will appear to work as long as you're only using parent 620dictionaries or standalone dictionaries, but as soon as you start using 621children, everything will fail horribly. 622 623 Type index zero, and type ID zero, are used to indicate that this 624type cannot be represented in CTF as currently constituted: they are 625emitted by the compiler, but all type chains that terminate in the 626unknown type are erased at link time (structure fields that use them 627just vanish, etc). So you will probably never see a use of type zero 628outside the symtypetab sections, where they serve as sentinels of sorts, 629to indicate symbols with no associated type. 630 631 The macros 'CTF_V2_TYPE_TO_INDEX' and 'CTF_V2_INDEX_TO_TYPE' may help 632in 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 634parent or child range. 635 636 It is quite possible and indeed common for type IDs to point forward 637in the dictionary, as well as backward. 638 639 640File: ctf-spec.info, Node: Type kinds, Next: Integer types, Prev: Type indexes and type IDs, Up: The type section 641 6422.3.3 Type kinds 643---------------- 644 645Every type in CTF is of some "kind". Each kind is some variety of C 646type: all structures are a single kind, as are all unions, all pointers, 647all arrays, all integers regardless of their bitfield width, etc. The 648kind 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 652plenty of room for expansion. It is likely that in future versions of 653the file format, types with smaller kinds will be more efficiently 654encoded than types with larger kinds, so their numerical value will 655actually start to matter in future. (So these IDs will probably change 656their numerical values in a later release of this format, to move more 657frequently-used kinds like structures and cv-quals towards the top of 658the space, and move rarely-used kinds like integers downwards. Yes, 659integers are rare: how many kinds of 'int' are there in a program? 660They're just very frequently _referenced_.) 661 662 Here's the set of kinds so far. Each kind has a '#define' associated 663with it, also given here. 664 665Kind Macro Purpose 666---------------------------------------------------------------------------------------- 6670 '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 6721 'CTF_K_INTEGER' An integer type. *Note Integer types::. 673 6742 'CTF_K_FLOAT' A floating-point type. *Note Floating-point types::. 675 6763 'CTF_K_POINTER' A pointer. *Note Pointers typedefs and cvr-quals::. 677 6784 'CTF_K_ARRAY' An array. *Note Arrays::. 679 6805 'CTF_K_FUNCTION' A function pointer. *Note Function pointers::. 681 6826 'CTF_K_STRUCT' A structure. *Note Structs and unions::. 683 6847 'CTF_K_UNION' A union. *Note Structs and unions::. 685 6868 'CTF_K_ENUM' An enumerated type. *Note Enums::. 687 6889 'CTF_K_FORWARD' A forward. *Note Forward declarations::. 689 69010 'CTF_K_TYPEDEF' A typedef. *Note Pointers typedefs and cvr-quals::. 691 69211 'CTF_K_VOLATILE' A volatile-qualified type. 693 *Note Pointers typedefs and cvr-quals::. 694 69512 'CTF_K_CONST' A const-qualified type. 696 *Note Pointers typedefs and cvr-quals::. 697 69813 'CTF_K_RESTRICT' A restrict-qualified type. 699 *Note Pointers typedefs and cvr-quals::. 700 70114 '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 705others. 706 707 708File: ctf-spec.info, Node: Integer types, Next: Floating-point types, Prev: Type kinds, Up: The type section 709 7102.3.4 Integer types 711------------------- 712 713Integral types are all represented as types of kind 'CTF_K_INTEGER'. 714These types fill out 'ctt_size' in the 'ctf_stype_t' with the size in 715bytes 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 718is always zero. 719 720 The variable-length data for integers has multiple items packed into 721it much like the info word does. 722 723Bit offset Name Description 724----------------------------------------------------------------------------------- 72524-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 72916-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 7340-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 738a sort of integral type with the 'isroot' bit flipped off and the offset 739and 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 741using slices of a full-width integer: *note Slices::.) 742 743 Integers that are bitfields usually have a 'ctt_size' rounded up to 744the nearest power of two in bytes, for natural alignment (e.g. a 17-bit 745integer would have a 'ctt_size' of 4). However, not all types are 746naturally aligned on all architectures: packed structures may in theory 747use integral bitfields with different 'ctt_size', though this is rarely 748observed. 749 750 The "encoding" for integers is a bit-field comprised of the values 751below, which consumers can use to decide how to display values of this 752type: 753 754Offset Name Description 755-------------------------------------------------------------------------------------------------------- 7560x01 'CTF_INT_SIGNED' If set, this is a signed int: if false, unsigned. 757 7580x02 '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 7620x04 '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 7660x08 '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 771supported: references to such types will be emitted as type 0. 772 773 774File: ctf-spec.info, Node: Floating-point types, Next: Slices, Prev: Integer types, Up: The type section 775 7762.3.5 Floating-point types 777-------------------------- 778 779Floating-point types are all represented as types of kind 'CTF_K_FLOAT'. 780Like integers, These types fill out 'ctt_size' in the 'ctf_stype_t' with 781the size in bytes of the floating-point type in question. They are 782always represented by 'ctf_stype_t', never 'ctf_type_t'. 783 784 This part of CTF shows many rough edges in the more obscure corners 785of 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 788just like integers do: 789 790Bit offset Name Description 791------------------------------------------------------------------------------------------- 79224-31 Encoding The desired display representation of this float. You can 793 extract this field with the 'CTF_FP_ENCODING' macro. See below. 794 79516-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 8000-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 804opaque, since there are no such things as floating-point bitfields in C: 805the bit-width should be filled out with the full width of the type in 806bits, and the offset should always be zero. It is likely that these 807fields 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 809parts. 810 811 The "encoding" for floats is not a bitfield but a simple value 812indicating the display representation. Many of these are unused, relate 813to Solaris-specific compiler extensions, and will be recycled in future: 814some are unused and will become used in future. 815 816Offset Name Description 817---------------------------------------------------------------------------------------------- 8181 'CTF_FP_SINGLE' This is a single-precision IEEE 754 'float'. 8192 'CTF_FP_DOUBLE' This is a double-precision IEEE 754 'double'. 8203 'CTF_FP_CPLX' This is a 'Complex float'. 8214 'CTF_FP_DCPLX' This is a 'Complex double'. 8225 'CTF_FP_LDCPLX' This is a 'Complex long double'. 8236 'CTF_FP_LDOUBLE' This is a 'long double'. 8247 'CTF_FP_INTRVL' This is a 'float' interval type, a Solaris-specific extension. 825 Unused: will be recycled. 8268 'CTF_FP_DINTRVL' This is a 'double' interval type, a Solaris-specific 827 extension. Unused: will be recycled. 8289 'CTF_FP_LDINTRVL' This is a 'long double' interval type, a Solaris-specific 829 extension. Unused: will be recycled. 83010 'CTF_FP_IMAGRY' This is a the imaginary part of a 'Complex float'. Not 831 currently generated. May change. 83211 'CTF_FP_DIMAGRY' This is a the imaginary part of a 'Complex double'. Not 833 currently generated. May change. 83412 '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 838possible that 'CTF_FP_CPLX' is meant to be used for only the real part 839of complex types, and 'CTF_FP_IMAGRY' et al for the imaginary part - but 840for now, we are emitting 'CTF_FP_CPLX' to cover the entire type, with no 841way to get at its constituent parts. There appear to be no uses of 842these encodings anywhere, so they are quite likely to change 843incompatibly in future. 844 845 846File: ctf-spec.info, Node: Slices, Next: Pointers typedefs and cvr-quals, Prev: Floating-point types, Up: The type section 847 8482.3.6 Slices 849------------ 850 851Slices, with kind 'CTF_K_SLICE', are an unusual CTF construct: they do 852not directly correspond to any C type, but are a way to model other 853types in a more convenient fashion for CTF generators. 854 855 A slice is like a pointer or other reference type in that they are 856always represented by 'ctf_stype_t': but unlike pointers and other 857reference types, they populate the 'ctt_size' field just like integral 858types do, and come with an attached encoding and transform the encoding 859of the underlying type. The underlying type is described in the 860variable-length data, similarly to structure and union fields: see 861below. Requests for the type size should also chase down to the 862referenced 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 867existence of slices: 'ctf_type_kind' never returns 'CTF_K_SLICE' but 868always the underlying type kind, so that consumers never need to know 869about slices: they can tell if an apparent integer is actually a slice 870if they need to by calling 'ctf_type_reference', which will uniquely 871return the underlying integral type rather than erroring out with 872'ECTF_NOTREF' if this is actually a slice. So slices act just like an 873integer with an encoding, but more closely mirror DWARF and other 874debugging information formats by allowing CTF file creators to represent 875a 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 878zero. The variable-length data for a slice is a single 'ctf_slice_t': 879 880typedef struct ctf_slice 881{ 882 uint32_t cts_type; 883 unsigned short cts_offset; 884 unsigned short cts_bits; 885} ctf_slice_t; 886 887Offset Name Description 888---------------------------------------------------------------------------------------- 8890x0 '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 8930x4 '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 9040x6 '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 911File: ctf-spec.info, Node: Pointers typedefs and cvr-quals, Next: Arrays, Prev: Slices, Up: The type section 912 9132.3.7 Pointers, typedefs, and cvr-quals 914--------------------------------------- 915 916Pointers, 'typedef's, and 'const', 'volatile' and 'restrict' qualifiers 917are represented identically except for their type kind (though they may 918be treated differently by consuming libraries like 'libctf', since 919pointers affect assignment-compatibility in ways cvr-quals do not, and 920they may have different alignment requirements, etc). 921 922 All of these are represented by 'ctf_stype_t', have no variable data 923at all, and populate 'ctt_type' with the type ID of the type they point 924to. 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 930Data models::), i.e. in practice, from the target machine ABI, and is 931not explicitly represented. The size of other kinds in this set should 932be determined by chasing ctf_types as necessary until a 933non-typedef/const/volatile/restrict is found, and using that. 934 935 936File: ctf-spec.info, Node: Arrays, Next: Function pointers, Prev: Pointers typedefs and cvr-quals, Up: The type section 937 9382.3.8 Arrays 939------------ 940 941Arrays are encoded as types of kind 'CTF_K_ARRAY' in a 'ctf_stype_t'. 942Both 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 944always zero. 945 946typedef struct ctf_array 947{ 948 uint32_t cta_contents; 949 uint32_t cta_index; 950 uint32_t cta_nelems; 951} ctf_array_t; 952 953Offset Name Description 954---------------------------------------------------------------------------------------- 9550x0 'uint32_t cta_contents' The type of the array elements: a type ID. 956 9570x4 '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 9640x8 '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 970size of the 'cta_contents' type by the 'cta_nelems'. 971 972 973File: ctf-spec.info, Node: Function pointers, Next: Enums, Prev: Arrays, Up: The type section 974 9752.3.9 Function pointers 976----------------------- 977 978Function pointers are explicitly represented in the CTF type section by 979a type of kind 'CTF_K_FUNCTION', always encoded with a 'ctf_stype_t'. 980The 'ctt_type' is the function return type ID. The 'vlen' in the info 981word 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 983the 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 986inserted to maintain alignment. 987 988 989File: ctf-spec.info, Node: Enums, Next: Structs and unions, Prev: Function pointers, Up: The type section 990 9912.3.10 Enums 992------------ 993 994Enumerated 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 996data model (enum bitfields are implemented via slices). The 'vlen' is a 997count of enumerations, each of which is represented by a 'ctf_enum_t' in 998the vlen: 999 1000typedef struct ctf_enum 1001{ 1002 uint32_t cte_name; 1003 int32_t cte_value; 1004} ctf_enum_t; 1005 1006Offset Name Description 1007------------------------------------------------------------------------ 10080x0 'uint32_t cte_name' Strtab offset of the enumeration name. 1009 Must not be 0. 1010 10110x4 'int32_t cte_value' The enumeration value. 1012 1013 1014 Enumeration values larger than 2^32 are not yet supported and are 1015omitted from the enumeration. (v4 will lift this restriction by 1016encoding 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, 1022and do not conflict with non-enums, structs, or unions with the same 1023name. 1024 1025 1026File: ctf-spec.info, Node: Structs and unions, Next: Forward declarations, Prev: Enums, Up: The type section 1027 10282.3.11 Structs and unions 1029------------------------- 1030 1031Structures and unions are represnted as types of kind 'CTF_K_STRUCT' and 1032'CTF_K_UNION': their representation is otherwise identical, and it is 1033perfectly allowed for "structs" to contain overlapping fields etc, so we 1034will 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, 1041but the type used to represent a structure field (and thus the size of 1042the variable-length array element representing the type) depends on the 1043size 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 1046rare: in v4, this representation will change somewhat for greater 1047compactness. It's inherited from v1, where the limits were much lower.) 1048 1049 Most structures can get away with using 'ctf_member_t': 1050 1051typedef 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 1062typedef 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 1072Offset Name Description 1073--------------------------------------------------------------------------------------------------------- 10740x00 'uint32_t ctm_name' Strtab offset of the field name. 1075 10760x04 '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 10800x08 '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 1084Offset Name Description 1085------------------------------------------------------------------------------------------------------------ 10860x00 'uint32_t ctlm_name' Strtab offset of the field name. 1087 10880x04 'uint32_t ctlm_offsethi' The high 32 bits of the offset of this field in bits. 1089 10900x08 'uint32_t ctlm_type' The type ID of the type of the field. 1091 10920x0c '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 1100collapsing the unnamed field's members into the containing structure or 1101union: this does mean that a structure containing an unnamed union can 1102end up being a "structure" with multiple members at the same offset. (A 1103future format revision may collapse 'CTF_K_STRUCT' and 'CTF_K_UNION' 1104into the same kind and decide among them based on whether their members 1105do in fact overlap.) 1106 1107 Structure and union type names, as usual in C, go into their own 1108namespace, just as enum type names do. 1109 1110 Forward declarations of structures and unions are not implemented 1111with this kind: *note Forward declarations::. 1112 1113 1114File: ctf-spec.info, Node: Forward declarations, Prev: Structs and unions, Up: The type section 1115 11162.3.12 Forward declarations 1117--------------------------- 1118 1119When the compiler encounters a forward declaration of a struct, union, 1120or enum, it emits a type of kind 'CTF_K_FORWARD'. If it later 1121encounters a non- forward declaration of the same thing, it marks the 1122forward as non-root-visible: before link time, therefore, 1123non-root-visible forwards indicate that a non-forward is coming. 1124 1125 After link time, forwards are fused with their corresponding 1126non-forwards by the deduplicator where possible. They are kept if there 1127is no non-forward definition (maybe it's not visible from any TU at all) 1128or if 'multiple' conflicting structures with the same name might match 1129it. Otherwise, all other forwards are converted to structures, unions, 1130or enums as appropriate, even across TUs if only one structure could 1131correspond to the forward (after all, all types across all TUs land in 1132the same dictionary unless they conflict, so promoting forwards to their 1133concrete 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 1137forward, we don't have an underlying type yet: if we did, we'd have 1138promoted it and this wouldn't be a forward any more) but with the 'kind' 1139of the forward. This means that we can distinguish forwards to structs, 1140enums and unions reliably and ensure they land in the appropriate 1141namespace even before the actual struct, union or enum is found. 1142 1143 1144File: ctf-spec.info, Node: The symtypetab sections, Next: The variable section, Prev: The type section, Up: CTF dictionaries 1145 11462.4 The symtypetab sections 1147=========================== 1148 1149These are two very simple sections with identical formats, used by 1150consumers to map from ELF function and data symbols directly to their 1151types. So they are usually populated only in CTF sections that are 1152embedded in ELF objects. 1153 1154 Their format is very simple: an array of type IDs. Which symbol each 1155type ID corresponds to depends on whether the optional _index section_ 1156associated with this symtypetab section has any content. 1157 1158 If the index section is nonempty, it is an array of 'uint32_t' string 1159table offsets, each giving the name of the symbol whose type is at the 1160same offset in the corresponding non-index section: users can look up 1161symbols in such a table by name. The index section and corresponding 1162symtypetab section is usually ASCIIbetically sorted (indicated by the 1163'CTF_F_IDXSORTED' flag in the header): if it's sorted, it can be 1164bsearched for a symbol name rather than having to use a slower linear 1165search. 1166 1167 If the data object index section is empty, the entries in the data 1168object and function info sections are associated 1:1 with ELF symbols of 1169type 'STT_OBJECT' (for data object) or 'STT_FUNC' (for function info) 1170with a nonzero value: the linker shuffles the symtypetab sections to 1171correspond with the order of the symbols in the ELF file. Symbols with 1172no name, undefined symbols and symbols named "'_START_'" and "'_END_'" 1173are skipped and never appear in either section. Symbols that have no 1174corresponding type are represented by type ID 0. The section may have 1175fewer entries than the symbol table, in which case no later entries have 1176associated types. This format is more compact than an indexed form if 1177most entries have types (since there is no need to record any symbol 1178names), but if the producer and consumer disagree even slightly about 1179which symbols are omitted, the types of all further symbols will be 1180wrong! 1181 1182 The compiler always emits indexed symtypetab tables, because there is 1183no symbol table yet. The linker will always have to read them all in 1184and always works through them from start to end, so there is no benefit 1185having the compiler sort them either. The linker (actually, 'libctf''s 1186linking machinery) will automatically sort unsorted indexed sections, 1187and convert indexed sections that contain a lot of pads into the more 1188compact, unindexed form. 1189 1190 If child dicts are in use, only symbols that use types actually 1191mentioned in the child appear in the child's symtypetab: symbols that 1192use only types in the parent appear in the parent's symtypetab instead. 1193So the child's symtypetab will almost always be very sparse, and thus 1194will usually use the indexed form even in fully linked objects. (It is, 1195of course, impossible for symbols to exist that use types from multiple 1196child dicts at once, since it's impossible to declare a function in C 1197that uses types that are only visible in two different, disjoint 1198translation units.) 1199 1200 1201File: ctf-spec.info, Node: The variable section, Next: The label section, Prev: The symtypetab sections, Up: CTF dictionaries 1202 12032.5 The variable section 1204======================== 1205 1206The variable section is a simple array mapping names (strtab entries) to 1207type IDs, intended to provide a replacement for the data object section 1208in dynamic situations in which there is no static ELF strtab but the 1209consumer instead hands back names. The section is sorted into 1210ASCIIbetical order by name for rapid lookup, like the CTF archive name 1211table. 1212 1213 The section is an array of these structures: 1214 1215typedef struct ctf_varent 1216{ 1217 uint32_t ctv_name; 1218 uint32_t ctv_type; 1219} ctf_varent_t; 1220 1221Offset Name Description 1222----------------------------------------------------------- 12230x00 'uint32_t ctv_name' Strtab offset of the name 1224 12250x04 'uint32_t ctv_type' Type ID of this type 1226 1227 There is no analogue of the function info section yet: v4 will 1228probably drop this section in favour of a way to put both indexed (thus, 1229named) and nonindexed symbols into the symtypetab sections at the same 1230time. 1231 1232 1233File: ctf-spec.info, Node: The label section, Next: The string section, Prev: The variable section, Up: CTF dictionaries 1234 12352.6 The label section 1236===================== 1237 1238The label section is a currently-unused facility allowing the tiling of 1239the type space with names taken from the strtab. The section is an 1240array of these structures: 1241 1242typedef struct ctf_lblent 1243{ 1244 uint32_t ctl_label; 1245 uint32_t ctl_type; 1246} ctf_lblent_t; 1247 1248Offset Name Description 1249------------------------------------------------------------- 12500x00 'uint32_t ctl_label' Strtab offset of the label 1251 12520x04 '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 1256is to use them to allow multiple disjoint namespaces in a single CTF 1257file, removing many uses of CTF archives, in particular in the '.ctf' 1258section in ELF objects). 1259 1260 1261File: ctf-spec.info, Node: The string section, Next: Data models, Prev: The label section, Up: CTF dictionaries 1262 12632.7 The string section 1264====================== 1265 1266This 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 1268assumed elsewhere in this spec). The strtab is usually ASCIIbetically 1269sorted to somewhat improve compression efficiency. 1270 1271 Where the strtab is unusual is the _references_ to it. CTF has two 1272string tables, the internal strtab and an external strtab associated 1273with the CTF dictionary at open time: usually, this is the ELF dynamic 1274strtab ('.dynstr') of a CTF dictionary embedded in an ELF file. We 1275distinguish between these strtabs by the most significant bit, bit 31, 1276of the 32-bit strtab references: if it is 0, the offset is in the 1277internal 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 1280version to have working support for external strtabs), the external 1281strtab is '.strtab' unless the 'CTF_F_DYNSTR' flag is set on the 1282dictionary (*note CTF file-wide flags::). Format v4 will introduce a 1283header field that explicitly names the external strtab, making this flag 1284unnecessary. 1285 1286 1287File: ctf-spec.info, Node: Data models, Next: Limits of CTF, Prev: The string section, Up: CTF dictionaries 1288 12892.8 Data models 1290=============== 1291 1292The data model is a simple integer which indicates the ABI in use on 1293this platform. Right now, it is very simple, distinguishing only 1294between 32- and 64-bit types: a model of 1 indicates ILP32, 2 indicats 1295LP64. The mapping from ABI integer to type sizes is hardwired into 1296'libctf': currently, we use this to hardwire the size of pointers, 1297function pointers, and enumerated types, 1298 1299 This is a very kludgy corner of CTF and will probably be replaced 1300with explicit header fields to record this sort of thing in future. 1301 1302 1303File: ctf-spec.info, Node: Limits of CTF, Prev: Data models, Up: CTF dictionaries 1304 13052.9 Limits of CTF 1306================= 1307 1308The 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 1330programs can and do exceed them: they will be lifted in format v4. 1331 1332 1333File: ctf-spec.info, Node: Index, Prev: CTF dictionaries, Up: Top 1334 1335Index 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 1721Tag Table: 1722Node: Top548 1723Node: Overview878 1724Node: CTF archive4165 1725Node: CTF dictionaries8791 1726Node: CTF Preamble9208 1727Node: CTF file-wide flags11818 1728Node: CTF header13276 1729Node: The type section19200 1730Node: The info word23865 1731Node: Type indexes and type IDs26395 1732Node: Type kinds29763 1733Node: Integer types33056 1734Node: Floating-point types36604 1735Node: Slices40629 1736Node: Pointers typedefs and cvr-quals44133 1737Node: Arrays45304 1738Node: Function pointers47035 1739Node: Enums47700 1740Node: Structs and unions48982 1741Node: Forward declarations52839 1742Node: The symtypetab sections54418 1743Node: The variable section57496 1744Node: The label section58634 1745Node: The string section59609 1746Node: Data models60871 1747Node: Limits of CTF61540 1748Node: Index62585 1749 1750End Tag Table 1751 1752 1753Local Variables: 1754coding: utf-8 1755End: 1756