Function recover_truncated_enum64_from 

fn recover_truncated_enum64_from(
    table: &[(&str, &str, u64)],
    type_name: &str,
    name: &str,
    lo32: u32,
) -> Result<u64>

Recover the true value of a 64-bit enum enumerator whose kernel BTF entry was truncated to its low 32 bits.

Kernels whose BTF was generated without BTF_KIND_ENUM64 support encode 64-bit enums as 8-byte BTF_KIND_ENUM entries whose enumerator values only carry the low 32 bits. This happens with pahole < 1.24, which predates ENUM64, and with pahole passing –skip_encoding_btf_enum64 (e.g. Google’s Container-Optimized OS / GKE kernels deliberately pass it for backward compatibility with older BTF consumers). The high bits can’t be recovered from kernel BTF, so substitute the value from the vmlinux.h this tree was built against, cross-checked against the low 32 bits the kernel did provide.

Note that this is a best-effort recovery, not a ground truth. The substitution assumes the running kernel agrees with this tree’s vmlinux.h on the high 32 bits, but only the low 32 bits can actually be verified. The cross-check is vacuous for enumerators whose value has no low bits set (e.g. SCX_DSQ_FLAG_BUILTIN, _SCX_ENQ_INTERNAL_MASK, SCX_ENQ_CLEAR_OPSS, SCX_ECODE*): their lo32 is 0 and matches anything, so those substitutions rest entirely on the high bits never moving. An enumerator missing from the table (a kernel newer than this tree’s vmlinux.h, or a stale autogen table) can’t be recovered at all. If a substitution is ever wrong, the scheduler operates on bogus values (e.g. dispatching to nonexistent DSQ ids or silently dropping flags) and can wildly malfunction, which is why the mismatch and table-miss paths refuse instead of guessing.