The CTF file or section itself has the following structure:
- +--------+--------+---------+----------+----------+-------+--------+
- | file | type | data | function | variable | data | string |
- | header | labels | objects | info | info | types | table |
- +--------+--------+---------+----------+----------+-------+--------+
+ +--------+--------+---------+----------+--------+----------+...
+ | file | type | data | function | object | function |...
+ | header | labels | objects | info | index | index |...
+ +--------+--------+---------+----------+--------+----------+...
+
+ ...+----------+-------+--------+
+ ...| variable | data | string |
+ ...| info | types | table |
+ +----------+-------+--------+
The file header stores a magic number and version information, encoding
flags, and the byte offset of each of the sections relative to the end of the
For each data object, the type ID (a small integer) is recorded. For each
function, the type ID of the return type and argument types is recorded.
+ For situations in which the order of the symbols in the symtab is not known,
+ a pair of optional indexes follow the data object and function info sections:
+ each of these is an array of strtab indexes, mapped 1:1 to the corresponding
+ data object / function info section, giving each entry in those sections a
+ name so that the linker can correlate them with final symtab entries and
+ reorder them accordingly (dropping the indexes in the process).
+
Variable records (as distinct from data objects) provide a modicum of support
for non-ELF systems, mapping a variable name to a CTF type ID. The variable
- names are sorted into ASCIIbetical order, permitting binary searching.
+ names are sorted into ASCIIbetical order, permitting binary searching. We do
+ not define how the consumer maps these variable names to addresses or
+ anything else, or indeed what these names represent: they might be names
+ looked up at runtime via dlsym() or names extracted at runtime by a debugger
+ or anything else the consumer likes.
The data types section is a list of variable size records that represent each
type, in order by their ID. The types themselves form a directed graph,
where each node may contain one or more outgoing edges to other type nodes,
- denoted by their ID.
+ denoted by their ID. Most type nodes are standalone or point backwards to
+ earlier nodes, but this is not required: nodes can point to later nodes,
+ particularly structure and union members.
Strings are recorded as a string table ID (0 or 1) and a byte offset into the
string table. String table 0 is the internal CTF string table. String table
unsigned char ctp_flags; /* Flags (see below). */
} ctf_preamble_t;
+typedef struct ctf_header_v2
+{
+ ctf_preamble_t cth_preamble;
+ uint32_t cth_parlabel; /* Ref to name of parent lbl uniq'd against. */
+ uint32_t cth_parname; /* Ref to basename of parent. */
+ uint32_t cth_lbloff; /* Offset of label section. */
+ uint32_t cth_objtoff; /* Offset of object section. */
+ uint32_t cth_funcoff; /* Offset of function section. */
+ uint32_t cth_varoff; /* Offset of variable section. */
+ uint32_t cth_typeoff; /* Offset of type section. */
+ uint32_t cth_stroff; /* Offset of string section. */
+ uint32_t cth_strlen; /* Length of string section in bytes. */
+} ctf_header_v2_t;
+
typedef struct ctf_header
{
ctf_preamble_t cth_preamble;
uint32_t cth_parlabel; /* Ref to name of parent lbl uniq'd against. */
uint32_t cth_parname; /* Ref to basename of parent. */
+ uint32_t cth_cuname; /* Ref to CU name (may be 0). */
uint32_t cth_lbloff; /* Offset of label section. */
uint32_t cth_objtoff; /* Offset of object section. */
uint32_t cth_funcoff; /* Offset of function section. */
+ uint32_t cth_objtidxoff; /* Offset of object index section. */
+ uint32_t cth_funcidxoff; /* Offset of function index section. */
uint32_t cth_varoff; /* Offset of variable section. */
uint32_t cth_typeoff; /* Offset of type section. */
uint32_t cth_stroff; /* Offset of string section. */
/* Data format version number. */
-/* v1 upgraded to v2 is not quite the same as native v2 (the boundary between
- parent and child types is different), and you can write it out again via
- ctf_compress_write(), so we must track whether the thing was originally v1 or
- not. If we were writing the header from scratch, we would add a *pair* of
- version number fields to allow for this, but this will do for now. (A flag
- will not do, because we need to encode both the version we came from and the
- version we went to, not just "we were upgraded".) */
+/* v1 upgraded to a later version is not quite the same as the native form,
+ because the boundary between parent and child types is different but not
+ recorded anywhere, and you can write it out again via ctf_compress_write(),
+ so we must track whether the thing was originally v1 or not. If we were
+ writing the header from scratch, we would add a *pair* of version number
+ fields to allow for this, but this will do for now. (A flag will not do,
+ because we need to encode both the version we came from and the version we
+ went to, not just "we were upgraded".) */
# define CTF_VERSION_1 1
# define CTF_VERSION_1_UPGRADED_3 2
ctt_type, which must be a type which has an encoding (fp, int, or enum). We
also store the referenced type in here, because it is easier to keep the
ctt_size correct for the slice than to shuffle the size into here and keep
- the ctt_type where it is for other types. */
+ the ctt_type where it is for other types.
+
+ In a future version, where we loosen requirements on alignment in the CTF
+ file, the cts_offset and cts_bits will be chars: but for now they must be
+ shorts or everything after a slice will become unaligned. */
typedef struct ctf_slice
{
uint32_t cts_type;
- unsigned char cts_offset;
- unsigned char cts_bits;
+ unsigned short cts_offset;
+ unsigned short cts_bits;
} ctf_slice_t;
typedef struct ctf_array_v1
projects / deliverable / binutils-gdb.git / blobdiff