[DTrace-devel] [PATCH REVIEW 0/3] support toolchain-ctf-generated kernels

[Nick Alcock]

The new(ish) toolchain CTF machinery has long been able to generate CTF for the
Linux kernel.  Since it generates CTF less than half the size of that produced
by the old dwarf2ctf deduplicator, higher quality (containing function type
signatures and with ambiguous types correctly represented rather than corrtuping
the type graph), *and* the deduplicator itself is much smaller (3000 lines or so
versus 6000 for dwarf2ctf), plus the in-kernel component is only 300 lines...
obviously we should support it.

But doing so is not trouble-free.  There are two places where DTrace needs a
little enhancement:

 - The CTF generated by GCC emits bitfields as slices rather than using the old
   "hack the base type" approach used by dwarfctf and Solaris.  While DTrace
   correctly identifies slices as bitfields (because if you ask what the
   encoding of a slice is, it looks exactly like the encoding of an old-style
   bitfield), slices can encode some things that the old approach could not
   possibly represent, like enum bitfields, bitfields of typedefs of ints, and
   the like. Such things appear as e.g.

     CTF_K_SLICE :4 -> CTF_K_TYPEDEF foo_t -> long int

   DTrace has to be taught that if it sees a bitfield it should try to look
   through it to see whether the underlying type is a typedef, enum, etc.

 - The type deduplicator used by GNU ld and the kernel's ctfarchive tool (under
   the covers, the ctf_link() machinery in binutils libctf) breaks cycles by
   turning structs and unions that appear in multiple TUs into forwards in the
   shared dict: some of these forwards may then be used in arrays, etc, in
   places where forwards are prohibited in C.  We have to teach DTrace to look
   through forwards and hunt down a plausible original type where possible: in
   particular, if ctf_type_size is later called on the type, this is essential,
   because ctf_type_size on a forward yields -ECTF_INCOMPLETE (unlike old
   Solaris libctf, which just returned a garbage size!).  This was somewhat
   whack-a-mole, but I think all relevant instances of ctf_type_size and
   ctf_type_resolve have been fixed up (we don't need to fix cases where we know
   they are called on integral types or slices, because neither of these can
   ever terminate in a forward).

With these in place, libctf-generated kernel CTF passes as many tests as
dwarf2ctf-generated CTF used to.

Nick Alcock (3):
  parser: support slices of typedefs, etc
  translators: procfs.d: rename projid_t
  parser, xlators, printf, cg, ident: resolve forwards to real types

 libdtrace/dt_cg.c     |  25 ++--
 libdtrace/dt_decl.c   |  18 ++-
 libdtrace/dt_ident.c  |   8 +-
 libdtrace/dt_impl.h   |   6 +
 libdtrace/dt_module.c | 129 +++++++++++++++++-
 libdtrace/dt_parser.c | 306 ++++++++++++++++++++++++++++++------------
 libdtrace/dt_parser.h |   2 +-
 libdtrace/dt_printf.c |  19 +--
 libdtrace/dt_xlator.c |  31 +++--
 libdtrace/dt_xlator.h |   2 +
 libdtrace/procfs.d.in |   4 +-
 11 files changed, 423 insertions(+), 127 deletions(-)

-- 
2.33.0.256.gb827f06fa9