tuples: Treat Type::timestamp as an array

[danobi]

Previously, we were seeing issues like:

$ sudo bpftrace -e 'BEGIN {@a[pid]=(nsecs, strftime("%M:%S", nsecs)); }'
FATAL: BUG: Struct size mismatch: expected: 24, real: 32
Aborted (core dumped)

on certain LLVM versions. The issue most likely has to do with padding
and whether LLVM considers the 16 byte type as a single 128 bit integer
or two 64 bit integers. If considered as a single 128 bit integer, then
the padded struct size is indeed 32 bytes. If as two 64 bit integers,
then 24 bytes is correct.

Instead of trying to fight with LLVM on this, mark Type::timestamp as an
array so that codegen will tell LLVM that Type::timestamp types are an
array of 16 8-bit integers. This effectively packs the type. We know
this is safe to do b/c Type::timestamp types are accessed from userspace
as two 64-bit integers anyways (see AsyncEvent::Strftime) which is
naturally packed on both 32-bit and 64-bit machines.

Note that this is also how Type::Usym is implemented.

Checklist

• Language changes are updated in docs/reference_guide.md
• User-visible and non-trivial changes updated in CHANGELOG.md
• The new behaviour is covered by tests

[danobi]

I think this is technically supposed to be correct:

diff --git a/src/types.cpp b/src/types.cpp
index 0c86bbc1..56a6fa8c 100644
--- a/src/types.cpp
+++ b/src/types.cpp
@@ -488,8 +488,10 @@ ssize_t SizedType::GetAlignment() const
     return GetSize();
   else if (GetSize() <= 4)
     return 4;
-  else
+  else if (GetSize() <= 8)
     return 8;
+  else
+    return 16;
 }

[danobi]

Chatted about this on IRC