Jordan Rome

@ajor Is the only issue here is the calling of `abort`? Can we just call `exit(1)` instead in the `LOG(FATAL)` path as this is dedicated to user errors?

> std::reference_wrapper's get() is another option, but it's so verbose :( TBH, I think I prefer the verbosity and the familiar `get` syntax over the API of the container ref....

> So I'm fine with going for this approach instead of having a custom operator if you think it's clearer. I prefer that approach but if other folks feel strongly...

Sorry for the delay. We're still discussing atomic map updates and the tradeoffs.

I think the larger ask here is exposing a way for bpftrace to access maps outside the ones it creates/defines in a script.

We should be able to support this now (with the addition of map declarations) but because there are restrictions on how you create and access this type of map it'll...

Nit: The commit message could use some more detail and perhaps an example.

I don't mean to hold up this PR but I got confused when I first saw this naming `bpftrace:signal:SIGUSR`. I read the conversation above and understand the reasoning but naming...

Should this also deprecate the ability to print maps when issuing a SIGUSR to bpftrace? Seems strange to have both. https://github.com/bpftrace/bpftrace/blob/master/man/adoc/bpftrace.adoc#map-printing

@viktormalik - Making sure you saw my comment above. What do you think about `self:signal:SIGUSR` instead of `bpftrace:signal:SIGUSR`?