Previously, map.lookup_or_init() may cause unexpected
return from the function when lookup finds no element and
init failed e.g. due to unlikely racy update or
sometimes hash table full.
This has caught surprise from many users. So, the commit
  https://github.com/iovisor/bcc/commit/ba64f031f2435aad5a85f8f37dbbe2a982cbbe6b
attempts to remove the early return in map.lookup_or_init().
But then since NULL pointer could be returned,
user will need to change their bpf program to check return value,
otherwise, verifier will reject the program.

As described in the above, such an API behavior change may cause
verifier failure and reject previously loadable bpf programs.
bcc should try to maintain API stability, esp. to avoid subtle
API behavior change.

This patch propose to restore the behavior of map.lookup_or_init()
and introduce a new one map.lookup_or_try_init(), which will
avoid unexpected return. The name is suggested by Alexei
to reflect that init may fail. map.lookup_or_try_init() will be formally
documented and used in bcc. A warning will be generated if
map.lookup_or_init() is used. Documentation will make it clear
that map.lookup_or_try_init() is preferred over map.lookup_or_init().

```
-bash-4.4$ sudo ./syscount.py
/virtual/main.c:71:11: warning: lookup_or_init() may return from the function, use loopup_or_try_init() instead.
    val = data.lookup_or_init(&key, &zero);
          ^
1 warning generated.
Tracing syscalls, printing top 10... Ctrl+C to quit.
...
```

All uses in examples and tools are converted to use
lookup_or_try_init(). Most tests are converted to use
lookup_or_try_init() too except test_trace_maxactive.py
and test_tracepoint.py to test lookup_or_init()
functionality.

* Allow lookup_or_init to return NULL (rather than just returning from the current function)
* Fixed a couple of bad edits found when running tests. Also fixed a bug in the
test runner. Also fixed a bug in libbcc where the python signature did not match
the actual implementation.

* fixed shebangs in tools (and lib)

* fixed shebangs in examples

* do not mangle shebangs in rpm spec

* renamed style-check.sh to c-style-check.sh

* factored out python linter to a separate file

* added shebang validation to the py-style-check

* added shebangs to all python executables

* Skip all dereferences inside bpf_probe_read calls

If the user decides to rely on a manual call to bpf_probe_read, we
don't try to rewrite its last argument.  This is needed as the
rewriter starts to recognize and rewrite more and more dereferences.

* tools: fix dereferences following 1a765a17

Currently, slabratetop always included slub_def.h. For the system uses
SLAB, the definition of 'struct kmem_cache' is different and the eBPF
program would fetch the wrong field and print garbages.

Signed-off-by: Gary Lin <glin@suse.com>

Conform to bytes encoding for some portion of the tools/tests, such that
smoke tests pass on python3. More conversions are surely required.

Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Several python tools allow their eBPF code to be printed to
stdout for debugging.  There are other projects that would
like to share these program definitions however, instead of
duplicating code.  We previously agreed on an --ebpf option
and we now continue adding it to more tools.

Signed-off-by: Nathan Scott <nathans@redhat.com>

This fixes the bcc module and all the affected tools for issues related to string handling in Python 3. Specifically, when passing Python strings to C libraries they are encoded as ASCII, and when constructing Python strings from C strings, they are decoded first.