This is essential for architecture which do have overlapping address space.
- bpf_probe_read_kernel() shall be used for reading data from kernel space
to the bpf vm.
- bpf_probe_read_user() shall be used for reading data from user space
  to the bpf vm.

Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>

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

Many tools rely on the user to type Ctrl-C to end, but don't actually
catch the keyboard interrupt and thus show an ugly backtrace when it
happens. Let's catch the interrupt.

* Add perl* utools man page links

Matches other languages, related to commit 9162be45.

* uthreads: explicitly list C as supported

uthreads supports C (pthreads) thread tracing, make this explicit.

Earlier use of -l java and -l none unchanged.

Add the corresponding man page and usage examples.

* Add Tcl support for ucalls / uflow / uobjnew / ustat

For some reason we need to use proc__args instead of proc__entry
in uflow.py to get similar results as with e.g. Python.

Python 3 fix, similar to commit 99d14683 and commit 4e4c9e01 for ucalls.

Closes #1996.

Use argparse in cachestat, add --ebpf support.

Add --ebpf support for u* tools, finalize language sorting.

Remove sole --ebpf string on usage line in tcpsubnet.

Sort language entries while at it.

* cc: bcc function to detect the language of a process

bcc_procutils_language looks into /proc/$pid/cmdline, /proc/$pid/exe,
and /proc/$pid/maps to determine the language.
Python wrapper takes a list of candidate languages; if the detected
language is not part of the list, None is returned.

* u* tools: automatically detect the language

Uses the detect_language bcc helper. -l switch can override the
detected language. In uthreads and ucalls, the language can be
overwritten to 'none' to trace pthreads and syscalls respectively.

All tools use the -l switch to set the language, for consistency.

* Travis CI build to check compliance with PEP8

* argdist: linter cleanup

* dbslower: linter cleanup

* dbstat: linter cleanup

* memleak: linter cleanup

* syscount: linter cleanup

* tplist: linter cleanup

* trace: linter cleanup

* ucalls: linter cleanup

* uflow: linter cleanup

* ugc: linter cleanup

* uobjnew: linter cleanup

* ustat: linter cleanup

When the target process is missing the required USDT probes, it can
be a simple mistake (e.g. attaching a script as Java to a Python
process), or a runtime that is not instrumented with the required
probes. Attempt to gracefully handle the error and print a helpful
message instructing the user why the error might have occurred.

```
$ uthreads -l java $(pidof python)
Error attaching USDT probes: the specified pid might not contain
the given language's runtime, or the runtime was not built with the
required USDT probes. Look for a configure flag similar to
--with-dtrace or --enable-dtrace. To check which probes are present
in the process, use the tplist tool.
```

Introduce PHP support to ucalls, uflow, and ustat. The PHP probes
used are for function entry and exit, file compile (~ class load),
and exception throw. This requires a PHP runtime built with the
`--enable-dtrace` configure switch. Some probes also require
USE_ZEND_DTRACE=1.

Resolves #945.

This tool traces method executions and prints out messages
with a nesting depth indicator that allows relatively easy
visualization of program flow. To reduce overhead, `-C` and
`-M` switches take class and method prefixes to filter the
output by. The filtering takes place in the BPF program, so
the unnecessary data never ends up in user space.

Usage examples:

```
uflow java 185
uflow -M index python 180
uflow -C 'IRB::Irb' ruby 10041
```

Skeletons for method flow, object allocations, general
event statistics, and thread statistics.