User-space stacks are quite special in regards to aggregation (and
comparison) between processes. To a first approximation, each pid has a
different memory mapping and thus pointers should not be compared or
aggregated between pids[*]. With ASLR this becomes even more fun, and
thus it is necessary to do usym()-style packing of the stackid for
ustack (since bpf_get_stackid will give you a hash of the pointers --
even in the ustack case).

However, the kernel address space is the same regardless of current->pid
-- and in many cases you want to aggregate between different processes
(and if not, you can always do the packing yourself with @[tid,stack]).

So, we only apply the packing when dealing with ustack. sym() already
does the right thing.

[*] This is more than slightly untrue -- really this depends on
    current->mm and ideally we would aggregate ustack on current->mm.
    Unfortunately this is not a luxury we have at the moment.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Fix USAGE message (issue 191)

- Stop warning about '-h'
- Sort options alphabetically
- Cosmetic changes

Fix 'lhist() 0 entry has 0M' (issue 63)

opensnoop to trace openat

rename name builtin to probe

Use env to find bpftrace

Fixlets

Ensure no garbage in struct sigaction.
Valgrind was complaining:

==21435== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==21435==    at 0x95ED000: __libc_sigaction (in /usr/lib64/libc-2.27.so)
==21435==    by 0x594E99: main
==21435==  Address 0x1ffefff8e8 is on thread 1's stack
==21435==  in frame #0, created by __libc_sigaction (???:)

Valgrind was complaining:

==8428== 32,816 bytes in 1 blocks are definitely lost in loss record 983 of 985
==8428==    at 0x4C2EDA7: malloc (vg_replace_malloc.c:299)
==8428==    by 0x96779A5: __alloc_dir (in /usr/lib64/libc-2.27.so)
==8428==    by 0x9677AAC: opendir_tail (in /usr/lib64/libc-2.27.so)
==8428==    by 0x59EC50: bpftrace::list_dir(...)
==8428==    by 0x59ED5F: bpftrace::list_probes(...)
==8428==    by 0x594993: main

cppcheck was complaining:

[attached_probe.cpp:206]: (warning) %d in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'.
[attached_probe.cpp:206]: (warning) %d in format string (no. 2) requires 'int *' but the argument type is 'unsigned int *'.
[attached_probe.cpp:206]: (warning) %d in format string (no. 3) requires 'int *' but the argument type is 'unsigned int *'.

While at it, check uname() and sscanf() return values to avoid garbage.

Valgrind was complaining:
==9103== Warning: invalid file descriptor -1 in syscall close()
==9103== Warning: invalid file descriptor -1 in syscall close()

issue 174 make resolve_kname match exact string

probe type short names 

Add file globbing search semantics to list_probes()

Support printf("%s") for stack and ustack

This works similarly to how printf'ing a Type::usym works.

When verifying the printf format string we treat stack and ustack as
Type::string. BPFtrace:get_arg_values now knows how to resolve these.

Fixes #10

This makes cgroupid function to work fine when building with alpine.

Allow '.' in idents for golang

Supports:
- LLVM 5 (static build)
- LLVM 5
- LLVM 6
- LLVM 7

ClangParser: Don't exit if kernel headers are not found

When specifying a string literal attach point do not try to expand
wildcards if they are present.

This specifically is required for Go methods on pointer receivers,
which have a '*' in their symbol name.

Allow quoted string attach points so that you can match more than
[a-Z0-9].

This specific issue that this fixes is attaching to go
functions. These symbols are in the format '<package>.<function>' and
can contain unicode letters and digits.