C++ toolchain support

[stephenrkell]

Conceptually, very little is missing for us to introspect on C++. But one unfortunate thing is that dumpallocs.ml does not work on C++ source, so we will need a C++ified version of that anyway... there is at least one C++ clang-based tool in toolsub that would be a good base.

Continuing that thought: if it uses (built-in) operator new then we need to add this to our list of allocation functions. The binary analysis (objdumpallocs / objdumpmeta) should have no trouble with this. At source level, the built-in operator new is polymorphic, but at linker level it always seems to come out as operator new[](unsigned long). If I write a simple bit of C++ code that does new...

$ diff -u <( objdump -rd test.o ) <( objdump -rd test.o| c++filt )
--- /dev/fd/63  2024-03-06 11:14:14.893088042 +0000
+++ /dev/fd/62  2024-03-06 11:14:14.893088042 +0000
@@ -10,40 +10,40 @@
    4:  48 83 ec 10             sub    $0x10,%rsp
    8:  bf a8 00 00 00          mov    $0xa8,%edi
    d:  e8 00 00 00 00          callq  12 <main+0x12>
-                       e: R_X86_64_PLT32       _Znam-0x4
+                       e: R_X86_64_PLT32       operator new[](unsigned long)-0x4
   12:  48 89 45 f8             mov    %rax,-0x8(%rbp)
   16:  be 2a 00 00 00          mov    $0x2a,%esi
   1b:  48 8d 3d 00 00 00 00    lea    0x0(%rip),%rdi        # 22 <main+0x22>
                        1e: R_X86_64_PC32       e+0xc
...

So in our C++ified version ofdumpallocs.ml, as well as doing the sizeofness analysis for C-style allocation functions (or maybe the generalised version of it mooted in #63), we need something simpler for C++ that can dump the source type of a built-in operator new application.

[stephenrkell]

The idea of cccppp (in toolsub) is to do a minimal rewriting of C++ source using the Clang tools API, which offers characterwise rewriting of files. The only rewriting we do is to templatify all built-in operators, including sizeof, e.g. an application of sizeof (T) gets rewritten to __operator_sizeof<T>()(). A vanilla definition of __operator_sizeof, in a prelude header, would just do the built-in sizeof.

Then it would be fun to see if the right alternative definition of __operator_sizeof can do the analysis for us, using expression template tricks. My fear is that it might only work in single-expression cases, e.g. malloc(sizeof (struct foo) + 4 * sizeof (int)) is doable but size_t sz = sizeof (struct foo) + 4 * sizeof (int); malloc(sz); breaks out of the expression template. There is room for further tricks like heuristically replacing size_t by auto, but at that point it is probably better to write the actual analysis we want directly over the Clang AST (hmm... given the complexity of that, not sure! though with the consequent DWARF output it could be contributed upstream, so would get maintained).

[difcsi]

I think it may be a good idea to wait for C++26 with this

https://isocpp.org/files/papers/P2996R4.html

[stephenrkell]

Thanks @difcsi -- that is interesting!

(On the other hand, we may not be free to compile all existing codebases in C++ 26 mode... surely many of them will not initially compile at that level.)