Fix the Markdown list in the README

snapcraft: add in some new tools missing from the snapcraft apps list

Add in bpflist and mysqld_qslower to apps list and re-order
dbstat in the list.
Signed-off-by: Colin Ian King <colin.king@canonical.com>

Use epoll in BPFPerfBuffer

bpflist: Add to tests and use Python directory listing

python: Allow module=None when resolving kernel symbols

Add build option for installing C++ examples

Smoke tests for the tools

This commit adds basic smoke tests for most tools in tools/ by
running the tool with either a short duration, or interrupting it
with a SIGINT after a short duration. The tests check the return
value from the tool to detect any Python exceptions or other
errors, but they do not read the standard error or standard output
and parse the tool's result.

Some tools are not covered by these smoke tests for reasons
documented in the test itself:

* btrfsdist and btrfsslower need btrfs
* cachetop doesn't like to run without a terminal
* dbslower, dbstat, and mysqld_qslower need a database engine
* deadlock_detector allocates a huge amount of memory
* softirqs doesn't work on new kernels and needs fixing (#1031)
* ugc needs a USDT-enabled runtime with GC probes
* zfsdist and zfsslower need zfs

This is a good place to start, but clearly for some tools,
especially those with a complex interface like trace and argdist,
we need more than just basic smoke tests.

syscount: Use ausyscalls if available to get syscall list

bpflist: Display processes with running BPF programs and maps

Prepare debian changelog for v0.3.0 tag

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

This tool displays processes with running BPF programs and maps,
and also optionally kprobes and uprobes. This is a poor-man's version
that snoops BPF file descriptors, as proposed by @brendangregg.

Example:

```
PID    COMM             TYPE     COUNT
4058   fileslower       prog     4
4058   fileslower       map      2
4106   bashreadline     map      1
4106   bashreadline     prog     1
```

Resolves #1036.

If ausyscall is installed, it can provide a clean, up-to-date list of
syscall numbers for the current architecture. This is much more useful
than the default hardcoded list for x86-64, which is currently used by
syscount.

Try to run `ausyscall --dump` and parse the output before resorting to
the static list. Tested on FC/Linux 4.9 and produces 327 syscalls.

Resolves #1001.

funclatency: remove unnecessary include

Added s390x support. Needs 4.10 Kernel

Restrict rewrite of unary operators to dereference operator

Since the whole expression, unary operator included, is replaced by a
call to bpf_probe_read, the dereference operator is currently the
only unary operator properly rewritten. When rewriting an increment
expression (++val) for instance, the increment operator is lost in
translation.

Trying to rewrite all unary operators sometimes confuses bcc and
results in improper code, for instance when trying to rewrite a
logical negation.

debuild: Do not parallelize tests

The tests in the test suite are not parallelizable and will fail if run
in parallel. Make the test step non-parallel to fix this issue.

Fix bpf_dins_pkt rewrite in BinaryOperator

cmake: Explicitly mark static libraries as such

filetop: support specifying sort column via cmdline argument

Some distros (e.g Fedora) override the default behaviour of building
static libraries to building dynamic ones instead. By explicitly
building the correct libraries as static, we make sure BCC properly
compiles everywhere.

Binary operator expressions where the left hand-side expression is a
reference to the packet are replaced by a call to the bpf_dins_pkt
helper. When replacing text, the Clang Rewriter tries to maintain a
list of offsets between the original and the new position of tokens.

Replacing the whole binary operator expression with the call to
bpf_dins_pkt confuses the Rewriter and it is unable to track the new
position of the right hand-side expression. Rewriting the binary
operator expression in two times without rewriting the right
hand-side expression itself solves the issue.

* 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

python: handle null module in BPF.sym

Symbol resolution with multiple executable regions per module

add XDP return values to python interface

The symbol resolution code used to assume for most purposes that
there is a single executable region per module. When there were
several, there was no crash, but symbols were not resolved correctly.
The reason is that the symbol offsets are relative to the first
executable region's start address, but bcc would resolve them
relative to the region in which they appeared. For example, given
the following regions and spans for a module libfoo.so loaded into
some process:

  1000-2000 r-xp libfoo.so
  2000-3000 rw-p libfoo.so
  3000-4000 r-xp libfoo.so
  4000-5000 r--- libfoo.so

Now, suppose there is a symbol bar() loaded at address 3500. In
the binary on disk, bar() is at offset 2500 from the beginning of
the module (but not the beginning of the 3000-4000 region!). When
we look at the candidate regions, we find 3000-4000, and discover
that 3500 lies within it. Then we subtract 3500-3000 to find the
offset from the beginning of the region, get 500, and now look
for a symbol that contains the relative address 500. As a result,
we might find some random symbol in the region 1000-2000, and
report that address 3500 corresponds to that random symbol rather
than to bar().

This commit fixes the situation by keeping only a single `Module`
instance for each module, even if that module spans multiple
executable regions. We remember all executable region start and
end ranges so we can determine whether an address (like 3500 in
the above example) lies within the module. But for the purpose of
finding the actual symbol, we need only the offset from the start
of the _first_ executable region, and then need to look up a symbol
based on that.

This was discovered and fixed while tracing .NET Core processes on
Linux, where libcoreclr.so (the main CLR binary) has several
executable regions. Resolving symbols from any but the first region
would produce totally bogus results.