[DTrace-devel] [oracle/dtrace-utils] b66215: parser: support slices of typedefs, etc

[Nick Alcock]

  Branch: refs/heads/nix/libctf
  Home:   https://github.com/oracle/dtrace-utils
  Commit: b662158b59c9ff0001ce9a74d40236a14b34dc8b
      https://github.com/oracle/dtrace-utils/commit/b662158b59c9ff0001ce9a74d40236a14b34dc8b
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2021-09-15 (Wed, 15 Sep 2021)

  Changed paths:
    M libdtrace/dt_parser.c

  Log Message:
  -----------
  parser: support slices of typedefs, etc

Slices in CTF are almost totally transparent to the user, *except* that
ctf_type_resolve will halt when it encounters a slice and will drill no
further, since going further would lose information about the encoding
of the slice.  Since you can have slices of typedefs, this means you
can't rely on ctf_type_resolve getting rid of all typedefs any more.

This change drills through to base types where necessary -- but I
suspect that what we actually want is a ctf_type_resolve_me_harder that
drills through slices too... but I have no idea what to call it
(ctf_type_resolve_base?), and user code will still need adjustment
because you cannot safely call ctf_type_encoding on a type returned from
such a function (the slice, if any, has been sheared away).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>


  Commit: e7d7c91353365c77790cbcd96606b30709e6fd80
      https://github.com/oracle/dtrace-utils/commit/e7d7c91353365c77790cbcd96606b30709e6fd80
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2021-09-15 (Wed, 15 Sep 2021)

  Changed paths:
    M libdtrace/procfs.d.in

  Log Message:
  -----------
  translators: procfs.d: rename projid_t

The Linux kernel already has a type named projid_t, with a definition
that conflicts with that in use (for an unused field) by this
translator.  libctf correctly diagnoses this as a conflict (where
libdtrace-ctf didn't): rename the type in the translator.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>


  Commit: 57ff5be999fbc45e80ff1dbce4f6e19115f42a80
      https://github.com/oracle/dtrace-utils/commit/57ff5be999fbc45e80ff1dbce4f6e19115f42a80
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2021-09-21 (Tue, 21 Sep 2021)

  Changed paths:
    M libdtrace/dt_cg.c
    M libdtrace/dt_decl.c
    M libdtrace/dt_ident.c
    M libdtrace/dt_impl.h
    M libdtrace/dt_module.c
    M libdtrace/dt_parser.c
    M libdtrace/dt_parser.h
    M libdtrace/dt_printf.c
    M libdtrace/dt_xlator.c
    M libdtrace/dt_xlator.h

  Log Message:
  -----------
  parser, xlators, printf, cg, ident: resolve forwards to real types

In contrast to libdtrace-ctf (which didn't reliably handle conflicted
structs and unions at all and often just assumed they weren't
conflicting, leading to corrupted type graphs), libctf's deduplicator
reliably identifies conflicted structs and unions, and avoids getting
caught in cycles while maximizing the number of shared types by
routinely converting conflicted structs and unions into forwards and
leaving the forward in the shared dict as a marker.

This means that forwards can and do appear in the shared graph in places
where they would be forbidden in C because there are things you can't do
with incomplete types: you can see things like arrays of forwards.  We'd
rather not inflict this on our users, so introduce a new dt_type_resolve
which is like ctf_type_resolve except that rather than returning a
forward when called on a type in the shared dict, it hunts through the
module list for the first non-forward with a matching name and suitable
kind (so a forward to 'struct foo' will only match a real 'struct foo',
not 'union foo'), returning the dict as well.  It only returns a forward
if no suitable complete type is found in any module at all.

This search can be relatively expensive, because it might involve
loading lots of modules, but it only happens when conflicted forwards
are found, which isn't all that common: and correctness trumps
performance anyway.

This is made a bit more complex because there were several places where
we weren't bothering to call ctf_type_resolve at all but where a
resolution is nonetheless required in any case (e.g. dt_idsize_type)
and a number of places where we were just *assuming* that
ctf_type_resolve succeeded (most unwise).  There are also a number of
places where we need to track both the fp of the original type and the
fp of the resolved type, notably in xlator-related code.

A couple of places have to *avoid* searching for real types, in
particular if a forward is found in the C and D dicts: dt_type_resolve
takes a flag to turn this off.  This was spotted heuristically (i.e.
a test failed): I don't *think* there are any places where this needs
doing that I missed, but I could be wrong.

(In the future some of this commit may be unwindable, if and when libctf
gains the ability to search for forwards in archives in the same way we
are doing here.  It seems like a worthwhile API addition.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>


Compare: https://github.com/oracle/dtrace-utils/compare/b662158b59c9%5E...57ff5be999fb