Types and Type Chains

The Actual Detail

The source being described, so every number below has a source you can point at:

struct Point { int x; int y; };

struct Nest {
    struct Point origin;
    char        label[8];
    uint32_t    flags;
    struct Point *next;
};

Here is the complete type graph, exactly as the reference binary records it. Offsets are .debug_info-relative and were confirmed against readelf and llvm-dwarfdump.

<0x5d> base_type  int                 byte_size 4
<0x41> base_type  unsigned int         byte_size 4
<0x48> base_type  long unsigned int    byte_size 8
<0x77> base_type  char                 byte_size 1

<0x64> typedef __uint32_t  -> <0x41>
<0x7e> typedef uint32_t     -> <0x64>
<0x8a> typedef ulong_t      -> <0x48>

<0x96> structure_type Point   byte_size 8
  <0xa1> member x  -> <0x5d> int    data_member_location 0
  <0xaa> member y  -> <0x5d> int    data_member_location 4

<0xb4> structure_type Nest    byte_size 32
  <0xbf> member origin -> <0x96> Point   offset  0
  <0xcb> member label  -> <0xf0> array   offset  8
  <0xd7> member flags  -> <0x7e> uint32_t offset 16
  <0xe3> member next   -> <0x100> pointer offset 24

<0xf0> array_type  -> <0x77> char
  <0xf9> subrange_type -> <0x48> upper_bound 7

<0x100> pointer_type  byte_size 8  -> <0x96> Point

Three verifications that this is a real type graph and not a plausible-looking invention:

1. The struct size is the sum of its members, rounded up.Point is 8: two 4-byte ints at 0 and 4. Nest is 32: a Point at 0 (8 bytes), char[8] at 8 (8 bytes), uint32_t at 16 (4 bytes), then a pointer at 24 — not 20, because a 4-byte field followed by an 8-byte field must be padded to keep the pointer 8-byte aligned. The padding is inferred from the offsets, and it is not recorded anywhere. The gap between 20 and 24 exists in the struct and has no DIE.
2. The chain terminates in a base type.flags is uint32_t, which is a typedef, which points at __uint32_t, which is another typedef, which points at unsigned int — a DW_TAG_base_type with no DW_AT_type. Three hops from a field to its four bytes.
3. Every reference is an offset into the same section.<0x100> is not an address; it is a byte offset in .debug_info. Reading it as a virtual address finds nothing, and on a PIE binary it finds nothing that looks plausible either.

The inclusive bound

label is declared char label[8]. The array DIE's child says:

Seven, not eight.DW_AT_upper_bound is an inclusive bound: valid indices run 0 to 7, so the element count is upper_bound + 1. This is a genuinely expensive mistake, because a pretty-printer that uses the value directly prints seven characters of an eight-character field and there is nothing anywhere that says the loop is wrong. The value is in range, the type is valid, and the output looks fine.

Two related things sit next to it. The index type is a separate type — DW_AT_type on the DW_TAG_subrange_type points at long unsigned int, not at int — because array indexing in C promotes to a large type, and a debugger that has to compute a byte offset needs the promoted width. And the subrange_type is a child of the array, not an attribute, which is what allows multidimensional arrays: each dimension is one child.