[DTrace-devel] [PATCH 2/7] types: populate intrinsics from the kernel if possible

[Kris Van Hees]

How does this patch fit in the way the type system for D is described in the
DTrace guide:

----> begin quote <----
Data Types and Sizes
D provides fundamental data types for integers and floating-point constants. Arithmetic may only be performed on integers in D programs. Floating-point constants may be used to initialize data structures, but floating-point arithmetic is not permitted in D. In Oracle Linux, D provides a 64-bit data model for use in writing programs. However, a 32-bit data model is not supported. The data model used when executing your program is the native data model that is associated with the active operating system kernel, which must also be 64-bit.

The names of the integer types and their sizes in the 64-bit data model are shown in the following table. Integers are always represented in twos-complement form in the native byte-encoding order of your system.

Table 2-3 D Integer Data Types

Type Name	64-bit Size
char            1 byte
short           2 bytes
int             4 bytes
long            8 bytes
long long       8 bytes

Integer types can be prefixed with the signed or unsigned qualifier. If no sign qualifier is present, it is assumed that the type is signed. The D compiler also provides the type aliases that are listed in the following table.

Table 2-4 D Integer Type Aliases

Type Name	Description
int8_t          1-byte signed integer
int16_t         2-byte signed integer
int32_t         4-byte signed integer
int64_t         8-byte signed integer
intptr_t        Signed integer of size equal to a pointer
uint8_t         1-byte unsigned integer
uint16_t        2-byte unsigned integer
uint32_t        4-byte unsigned integer
uint64_t        8-byte unsigned integer
uintptr_t       Unsigned integer of size equal to a pointer

These type aliases are equivalent to using the name of the corresponding base type listed in the previous table and are appropriately defined for each data model. For example, the uint8_t type name is an alias for the type unsigned char. See Type and Constant Definitions for information about how to define your own type aliases for use in D programs.

Note:The predefined type aliases cannot be used in files that are included by the preprocessor.
D provides floating-point types for compatibility with ANSI C declarations and types. Floating-point operators are not supported in D, but floating-point data objects can be traced and formatted with the printf function. You can use the floating-point types that are listed in the following table.

Table 2-5 D Floating-Point Data Types

Type Name	64-bit Size
float           4 bytes
double          8 bytes
long double     16 bytes

D also provides the special type string to represent ASCII strings. Strings are discussed in more detail in DTrace Support for Strings.
----> end quote <----

Most specifically, DTrace seems to be defining its own type system (obviously
based on standard systems) rather than using whatever the runtime system is
as presented by the runtime kernel.  As such, it seems to me that this patch
is not OK because it makes the type system dependent on the kernel rather than
D (DTrace) having its own well defined type system.

On Tue, May 02, 2023 at 06:12:17PM +0100, Nick Alcock via DTrace-devel wrote:
> The primary purpose of types in the C container, like types in DTrace in
> general, is not just to write D programs and #include C headers -- it's
> also to interoperate with the type system used by the kernel.
> 
> As such, we really should be getting types in this dict *from* the
> kernel if at all possible.  This also means we are insulated from the
> kernel suddenly changing its type system on us (being freestanding,
> the kernel can break platform ABI like that fairly freely, as it
> recently did with the unconditional unsignednessing of char); whatever
> the types are, we just pick them up, and then any types the users (or
> the D container, or the syslibs, or...) base on them will be compatible
> with whatever the kernel's definition is.
> 
> A lot of types in the _dtrace_intrinsics_* arrays are now redundant, but
> precisely which those *are* depends on the running kernel, so we leave
> the lot so that we can always use those types in D even if the kernel
> doesn't define them at all.  (But in practice all the useful ones will
> always come from vmlinux from now on -- except for void, which we
> define ourselves because of the IS_VOID() macro. Nobody's ever going to
> check void for assignment-compatibility anyway, and the definition of
> void in particular is woolly in CTF and different implementations have
> defined it in rather different ways.  Let's stick to one consistent
> intrinsic instead.)
> 
> Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
> ---
>  libdtrace/dt_open.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/libdtrace/dt_open.c b/libdtrace/dt_open.c
> index f0dc2575377f2..f0ef053f5274d 100644
> --- a/libdtrace/dt_open.c
> +++ b/libdtrace/dt_open.c
> @@ -939,10 +939,31 @@ dt_vopen(int version, int flags, int *errp,
>  	dmp->dm_flags = DT_DM_LOADED; /* fake up loaded bit */
>  
>  	/*
> -	 * Fill the dynamic "C" CTF container with all of the intrinsic
> -	 * integer and floating-point types appropriate for this data model.
> +	 * Fill the dynamic "C" CTF container with all of the intrinsic integer
> +	 * and floating-point types appropriate for this data model; but first,
> +	 * try to prepopulate them all from the vmlinux` container, so that our
> +	 * types are compatible with the kernel's type system.  Or at least,
> +	 * almost all of them: "void" has special hardwired behaviour in
> +	 * dt_parser.h and nobody's likely to check it for
> +	 * assignment-compatibility, so use the hardwired intrinsic for that
> +	 * unconditionally.
>  	 */
>  	for (; dinp->din_name != NULL; dinp++) {
> +		dtrace_typeinfo_t ti;
> +
> +		if (strcmp(dinp->din_name, "void") != 0 &&
> +		    dtrace_lookup_by_type(dtp, "vmlinux", dinp->din_name,
> +			&ti) == 0) {
> +			if (ctf_add_type(dmp->dm_ctfp, ti.dtt_ctfp,
> +				ti.dtt_type) != CTF_ERR)
> +				continue;
> +			else
> +				dt_dprintf("Attempt to add %s from the kernel "
> +				    "CTF failed: %s.  Using hardwired def.)\n",
> +				    dinp->din_name,
> +				    ctf_errmsg(ctf_errno(dmp->dm_ctfp)));
> +		}
> +
>  		if (dinp->din_kind == CTF_K_INTEGER) {
>  			err = ctf_add_integer(dmp->dm_ctfp, CTF_ADD_ROOT,
>  			    dinp->din_name, &dinp->din_data);
> -- 
> 2.39.1.268.g9de2f9a303
> 
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel