Memory Layout

C++ layout questions — how big is this type? where’s the padding? does it have a vtable? — usually mean squinting at a struct and doing arithmetic. The memory-layout tool answers them directly.

What it returns

memory_layout — for a given type (by ID or name), the type’s actual in-memory layout:

its size and alignment in bytes,
total padding,
whether it has a vtable pointer, and
an ordered map of byte regions that tiles the whole type from start to end — with no gaps and no overlaps.

Each region says what occupies it: a field (with its name and type), a base class subobject, the vtable pointer, or padding. Padding is a first-class, named region — not a number you have to infer — so the agent can see wasted space and where it sits, and reason about reordering or packing.

Requires debug info

This view is built from the debug information in a compiled artifact — DWARF from a -g build on Linux/macOS, or a PDB on Windows. It follows that:

a type with no debug info available returns a clear “no layout” response rather than a guess;
layouts reflect a specific build. After you rebuild, the agent should re-query rather than rely on an earlier answer. Treat layout as point-in-time. See Workspace & Indexing.

Quick layout vs. full map

For a fast size/alignment/padding readout without the full byte map, the agent can use the layout digest inside symbol_dossier. Reach for memory_layout when it needs the region-by-region breakdown.

Availability by build

If your project is built without debug info, layout queries won’t return data. The server can be run in a profile that omits this tool entirely for projects where layout isn’t available — see Configuration.

Windows (PDB): current limitations

On Windows the layout is read from the program’s PDB via the MSVC DIA SDK, with two caveats today:

64-bit only. Only x64 (LLP64) builds are supported — 32-bit (x86) and ARM64 PDBs aren’t read yet, so layout queries against those builds return “no layout.” Expect Windows sizes to differ from Linux/macOS for the same source (for example, long is 4 bytes on Windows vs. 8 elsewhere).
The PDB must sit next to the binary. The server locates it by convention as <binary>.pdb beside the compiled artifact. If your build redirects it with the linker’s /PDB:<path> flag, or it’s renamed or combined into another file, the server can’t find it and layout is unavailable — keep the PDB beside the binary (the MSVC default).