Alastair Robertson

Thanks for taking this on! It looks like there quite a lot of C code necessary to implement HDR histograms and converting that all to assembly like we’ve done for...

This would definitely be useful and is similar to something I've been thinking about. I won't have time to get around to it before #997 is done though, so if...

How about changing the output format, e.g. ``` @x[1,2,3] = 3 ``` Current: ``` {"type": "map", "data": {"@x": {"1,2,3": 4}}} ``` New, with complex keys: ``` {"type": "map", "data": {"name":...

Deleting scalar maps has actually been allowed since the very beginning of bpftrace. Here's an old example of a script using it: https://github.com/brendangregg/bpf-perf-tools-book/blob/09f8a3a101fdc23b0e51c33158ea3a1782aea427/originals/Ch14_Kernel/numamove.bt#L36-L37 It was actually #3300 which unintentionally changed...

Tagging this with v0.22 for now as the inability to suppress scalar map printing is a breaking change.

> Hm, my output on latest master (unless I did some mistake): > > ``` > # src/bpftrace test.bt > [...] > BPF program is too large. Processed 1000001 insn...

This gets weirder... This is my output with `-d verifier`, bearing in mind that the script runs for me without verifier complaints normally: ``` Attaching 1 probe... BPF verifier log...

FWIW I'm now also seeing the "BPF program is too large. Processed 1000001 insn" verifier error after upgrading from that 5.19 kernel to 6.9.

Sounds like a potential verifier bug then? Minimal repro: ``` BEGIN { @[1] = 1; if (len(@) > 1) { @res = 1; } } ``` Objdump of generated ELF...

This is definitely functionality that we need, but I'm not sold on the syntax. The name `has_key` doesn't make sense on a scalar - a scalar by definition will never...