Use fast compression in test deb builds

Builds on GCE/ubuntu image were taking a long time due to combination of
disk speed/single core, and the default dpkg-deb compression level
(-z9). The dpkg-deb alone step was taking up to 5 minutes. Reduce to ~1
minute by forcing -z1. Unfortunately, it was not obvious how to capture
the option in debuild command, so this is a bit hacky.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Fixes for LLVM4+, python3

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

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

In python3, output needs to be converted from ascii to str before the
"error_msg in str" test will succeed. This change should be backwards
compatible with python2.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Diff generated by clang-format
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Recent llvm changed the calling convention of setInvocation, breaking
3.9/4.0 compatibility. This new approach works for both.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Without marking as nounwind, recent llvm started generating .eh_frame
section, which is invalid for bpf target jit.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

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

Use PID to resolve path of target libraries

trace: fix for python3

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

tplist: don't fail if no verbosity is supplied

update tools pic

Initialise the verbosity argument to 0, so that when no verbosity is
provided we don't fail with

$ tplist
kvmmmu:kvm_mmu_pagetable_walk
unorderable types: NoneType() > int()

xrange does not exist in py3.

Add in capable, deadlock-detector, llcstat, mountsnoop, profile,
runqlen, solisten, tplist, ucalls, uflow, ugc, uobjnew, ustat
and uthreads. Includes some re-ordering as well.
Signed-off-by: Colin Ian King <colin.king@canonical.com>

bcc: add support for lpm trie map type

Update installation instructions for FC24 and FC25

docs/kernel-versions: add reference to powerpc64 constant blinding support

... introduced in v4.9
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>

It turns out that for FC24 and FC25, there is a sufficiently recent
version of Clang in the official package sources, so we don't need
to fetch it from llvm.org using wget. Tested manually on a pair of
fresh FC24 and FC25 VMs, and confirmed that BCC builds and runs OK.

tools: add tool to detect potential deadlocks in running programs

switch bcc to use single instance per bcc process, fixed issue #940

instance dir is bcc_pid, fixed issue #940

docs: fix "BPF attached to sockets" commit link

docs: keep track of when prealloc of map elements were introduced

- Specify when `--binary` is needed (statically vs dynamically-linked
  binaries).

- Make `-h`, `_examples.txt`, and man page have concrete examples and
  be more user-friendly.

- Remove dependency on networkx. I did this by copying only the parts I needed
  from networkx, and adapting it to only use what I needed. These include:
  `DiGraph`, `strongly_connected_components`, `simple_cyles`

- Symbolize global and static mutexes. In order to do this, I subshell out to
  `subshell`. This isn't very efficient, but this only happens at the end of
  the program if a deadlock is found, so it's not too bad.

- `--verbose` mode to print graph statistics

- Make `--binary` flag optional. Not needed by default, However, this is needed
  on kernels without this recent kernel patch
  (https://lkml.org/lkml/2017/1/13/585, submitted 2 weeks ago): we can't attach
  a uprobe on a binary that has `:` in the path name. Instead, we can create a
  symlink without `:` in the path and pass that to the `--binary` argument
  instead.

Kernel v4.6-rc1~91^2~108^2~6
 commit 6c9059817432 ("bpf: pre-allocate hash map elements")

Introduced default preallocation of mem elements to solve a deadlock
(when kprobe'ing the memory allocator itself).

This change is also a performance enhancement.

The commit also introduced a map_flags on BPF_MAP_CREATE, which can disable
this preallocation again BPF_F_NO_PREALLOC.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

`deadlock_detector` is a new tool to detect potential deadlocks (lock order
inversions) in a running process. The program attaches uprobes on
`pthread_mutex_lock` and `pthread_mutex_unlock` to build a mutex wait directed
graph, and then looks for a cycle in this graph. This graph has the following
properties:

- Nodes in the graph represent mutexes.
- Edge (A, B) exists if there exists some thread T where lock(A) was called
  and lock(B) was called before unlock(A) was called.

If there is a cycle in this graph, this indicates that there is a lock order
inversion (potential deadlock). If the program finds a lock order inversion, the
program will dump the cycle of mutexes, dump the stack traces where each mutex
was acquired, and then exit.

The format of the output uses a similar output as ThreadSanitizer (See example:
https://github.com/google/sanitizers/wiki/ThreadSanitizerDeadlockDetector)

This program can only find potential deadlocks that occur while the program is
tracing the process. It cannot find deadlocks that may have occurred before the
program was attached to the process.

If the traced process has many mutexes and threads, this program will add a
very large overhead because every mutex lock/unlock and clone call will be
traced. This tool is meant for debugging only, and you should run this tool
only on programs where the slowdown is acceptable.

Note: This tool adds a dependency on `networkx` for the graph libraries
(building a directed graph and cycle detection).

Note: This tool does not work for shared mutexes or recursive mutexes.

For shared (read-write) mutexes, a deadlock requires a cycle in the wait
graph where at least one of the mutexes in the cycle is acquiring exclusive
(write) ownership.

For recursive mutexes, lock() is called multiple times on the same mutex.
However, there is no way to determine if a mutex is a recursive mutex
after the mutex has been created. As a result, this tool will not find
potential deadlocks that involve only one mutex.