Viktor Malík

> Also moved the `libbpf_print` and `libbpf_print_level_string` functions from `main.cpp` to the shared `run_bpftrace.cpp` because `aot_main.cpp` needs them as well - it wasn't properly setting the log callback function for...

> We also discussed about `sargX` with @ajor and concluded it typically won't return the correct argument for other languages like Go. Yes, Go uses their own [calling conventions](https://tip.golang.org/src/cmd/compile/abi-internal#amd64-architecture) and...

> > > We also discussed about `sargX` with @ajor and concluded it typically won't return the correct argument for other languages like Go. > > > > > >...

> I don't like that this forces users to know the calling convention of whatever architecture they're running on. I'd say that improving our DWARF support and pushing everyone towards...

> > But, if the user doesn't have DWARF symbols for his binary, knows the ABI, and wants to see values of stack-passed args, why not let him do it,...

@danobi @jordalgo do you want to have one more look? Otherwise we can merge.

> So this is an RFC to re-work and codify these logging flavors. Here is the proposal: I generally like the below but have a few comments. > * `INFO`:...

> Does "exit via `ABORT`" mean something special or can `ERROR` just eventually trigger a clean exit? +1 here, we don't need to explicitly recommend exiting via `ABORT`, IIUC, `ABORT`...

> JC, what is the use case for logging errors that end in a clean exit? Or am I just getting hung up on the word "clean" - we should...

IIRC, we use the `retval` builtin for these cases. But since `retval` is listed as a field in listing, I guess that we could support `args.retval`, too. Shouldn't be too...