Is that the proposed workflow? (one of them at least)
My preferred workflow (as a C++ developer) would be to define those pretty printers directly in my C++ code.
I would imagine something like
struct {
byte* data;
size_t size;
__attribute__((clang::lldbformatters))
string_view __lldb_summary() { return string_view{data, size}; }
}
As mentioned by others before, directly calling the compiled function is not an option because of security and the slowness of expression evaluation.
But maybe we could teach clang to translate the __lldb_summary function into some bytecode in a separate section?
I have no glue whether eBPF support is even close to good enough for compiling C++ code (I never used eBPF before). But if we use a bytecode format for which there already is a LLVM-backend, we would be closer to that goal than if we use a completely new bytecode format.
Afaik, BPF was designed with the explicit goal of “sandboxing”, so BPF’s design goals should align well with our goals here. Not sure how we think about using a third-party libraries, but afaik there are libraries available for running eBPF code also in userland.
An alternative bytecode representation which comes to mind would be WebAssembly. WebAssembly was also designed with the primary design goal of security/sandboxing, and there also already is support a WebAssembly backend in LLVM