Alastair Robertson

> > I'd also add that `$myenum` should be displayed as a string in `print($myenum)` and `@[$myenum] = $myenum`. It would be a change in behaviour, but I'd say it's...

Enums being usable as integers is pretty much specific to C though. More modern languages mostly have stricter typing on them. BpfScript isn't trying to copy C and I'd say...

It seems that there are two issues here that can be separated: 1. Backwards compatibility 2. Enum type semantics **Backwards compatibility** Since we don't have any concept on an "enum"...

Also, it seems likely that at some point we'll want to let users define and use their own enums in BpfScript, so we'll need to take that into account too.

It's bpftrace that does the symbol resolution already in [resolve_offset_uprobe_multi](https://github.com/bpftrace/bpftrace/blob/d592be8fe65d7b49aa183eb1a05625df1743ed0c/src/attached_probe.cpp#L1030-L1034). Then we just pass the raw offsets to the kernel here: https://github.com/bpftrace/bpftrace/blob/d592be8fe65d7b49aa183eb1a05625df1743ed0c/src/attached_probe.cpp#L1102

I don't think there are any kernel settings to configure. Have you got a recent version of libbpf? Looks like it'll need 1.3 or newer: https://github.com/libbpf/libbpf/releases

> Be aware this is something might been already fixed in kernel side at least for x86: https://lore.kernel.org/all/[email protected]/ > > Also it might worth the take a look if #3095...

> Unfortunately, this won't work. We don't distinguish between `my_func+0` and `my_func`, so in both case we'll call to LLDB in order to skip the prologue. I've opened an issue...

Yes, exactly like the tracepoint_order/kprobe_order/etc. tests (I'd forgotten we had those!), but for all the probe types we support.

I think throwing an exception from the `LOG(FATAL)` path and catching it in `main()` would be more future-proof: it'll perform call destructors for all living objects so any RAII cleanups...