Jordan Rome

@lenticularis39 Thanks for working on this! Similar to @ajor I'm starting to play with it and just documenting some random issues. --- This yields a verifier error for the unused...

> Maybe https://github.com/bpftrace/bpftrace/issues/3126 is the solution for this bug as well? When reading a per-cpu map value, collect data from all CPUs. Yeah that makes sense. I'll try to pick...

This is fixed here: https://github.com/bpftrace/bpftrace/pull/3189

> I'm sometimes using INFO for debugging but DEBUG is better for that purpose as it shows the file name and the line number. So, I'm in favor of keeping...

Updated proposal: - `DEBUG`: log info to the user regardless of log level - like using stdout (comes with file and line number). No prefix. - `V1`: log info to...

> How about VERBOSE instead of V1 if we're only having one verbosity level? I prefer V1 mostly because VERBOSE is well... verbose. I was also thinking of changing WARNING...

@ajor and I were discussing offline and it seems like there are still some sticking points with `LOG(ERROR)` and `LOG(ABORT)`/`LOG(FATAL)`. One of the issues is that `abort`ing or `exit`ing from...

Closing this as it's been mostly resolved over multiple PRs: https://github.com/bpftrace/bpftrace/pull/3164 https://github.com/bpftrace/bpftrace/pull/3091 https://github.com/bpftrace/bpftrace/pull/3202

I'm leaning toward @danobi's suggestion of adding an async print builtin. It's more explicit and removes the need for map copying.

> Why not the explicit map references approach (https://github.com/bpftrace/bpftrace/issues/3028#issuecomment-2010250450)? While maybe the underlying implementation might be the same between `aprint(@map)` and `print($map_ref)`, the syntax for printing map references doesn't really...