Upstream, params() was renamed to parameters(). In order to support both
old and new LLVM, use the unchanged param_begin and param_end API.
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

* libbcc: fix off-by-one errors in resolving adjacent modules/symbols, add test

* libbcc: use binary search in ProcSyms::Module::find_addr()

Add ctypes declarations for `bpf_attach_tracepoint` and
`bpf_detach_tracepoint` in libbcc.py. It works anyway, but now
it's a bit safer.

cpudist: Support off-cpu time reports

bcc: Tracepoint support in libbpf and BPF

The test asserts that we can enable the sched_switch tracepoint and read
some events from it. The test is also marked to require kernel 4.7 or
later, because that's where the BPF support for tracepoints was introduced.

It seems from experimentation that the calculated timestamps between
on- and off-CPU switch events can produce incorrect results, with a
later event having a smaller timestamp. Discard events when the
resulting delta time would be negative.

The `sched_switch` tracepoint approach requires storing the previous
task's tgid in a map and fetching it from there, because it is not
available as a tracepoint argument. Instead, placing a kprobe on the
`finish_task_switch` function allows cleanly fetching the previous
task's pid and tgid from the task_struct.

When the `-O` switch was provided, cpudist was unnecessarily filtering
out scheduling events arising from a task waking up when the previous
task was not running. On an idle system, this happens a lot, and causes
events to be missed. This is now fixed.

Use `/proc/$PID/comm`, which may fail, for example if the original
process already exited. This may also produce misleading results
if another process got the same pid, but there's no way around this.

Add -O switch, which directs cpudist to collect off-CPU time
statistics. Also restructure the code slightly and added examples
as appropriate.

Introduce tracepoint support in libbpf via new `bpf_attach_tracepoint`
API, which takes the tracepoint category and name (e.g. "sched",
"sched_switch"). Attach the tracing program to the tracepoint's id
and proceed as usual.

Add `attach_tracepoint` API to Python BPF module, which takes the
tracepoint description as a single string (e.g. "sched:sched_switch").
Load the BPF program with bpf_prog_type set to TRACEPOINT and then
call `bpf_attach_tracepoint` to attach it.

Due to an incorrectly referenced global variable, specifying a pid
to filter with a kernel probe produced an error. This is now fixed,
for example:

```
TIME     PID    COMM         FUNC
23:46:00 29967  bash         sched_switch
23:46:01 29967  bash         sched_switch
23:46:01 29967  bash         sched_switch
^C
```

* cpudist: summarize on-CPU time per task as a histogram

This is the initial implementation of the tool itself, which uses
the sched:sched_switch tracepoint to probe task switches. This is
a slightly more robust approach than using a kernel function, such
as finish_task_switch.

When native BCC support for tracepoints is introduced, this tool
can be reimplemented and reliance on the current Tracepoint module
can be removed.

* cpudist: add man page and examples

tools: fix getting {ext4,btrfs}_file_operations address (ref #583)

ext4slower: fix getting kallsyms address

$ grep ext4_file_operations /proc/kallsyms
ffffffffc0331340 r ext4_file_operations	[ext4]

* tcpretrans: support full IPv6 addresses, fix --lossprobe

* tcpaccept: support full IPv6 addresses, fix timestamps

* tcpconnect: support full IPv6 addresses, fix timestamps

* tcpconnlat: support full IPv6 addresses, fix timestamps

Update installation instructions for Fedora

clang 3.7.0 is known to be buggy, and we recommend that people use
3.7.1. Update install instructions to point to 3.7.1.

Compiling BCC on Fedora requires elfutils-libelf-devel. Add this
package to the install instructions for Fedora.

Do not throw exception on ipv6 packets in tcpretrans

* kernel version guide

* update

Fix nits for /tmp/perf-pid.map support

Add support for reading symbols from /tmp/perf-pid.map

fix install instruction to mention llvm >= 3.7.1

Signed-off-by: Alexei Starovoitov <ast@fb.com>

This adds basic support for /tmp/perf-pid.map. To cope with processes in
containers, it supports:

* mapping from BCC's PID namespace to the target process's PID namespace
  using /proc/pid/status
* resolving a target process's root filesystem using /proc/pid/root

Check for NULL result from bpf_attach_kprobe

The check for NULL in the return value from C functions was comparing to
None incorrectly, causing an error check to pass improperly. Simply
check the truthiness of the return instead seems to be more resilient.

Add a test as well.

Fixes: #568
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

libbpf.c: Prepend BPF syscall error to log_bug when debug is enabled.

When BPF syscall fails and DEBUG_FLAG has been provided to a Python
caller script, the BPF error string would be printed only if log_buf had
not been filled by the kernel. This commit removes this requirement,
printing the error string even if log_buf is not empty.
Signed-off-by: Quentin Monnet <quentin.monnet@6wind.com>

Commit 759029fe provided an option to
store the output from BPF syscall into a buffer (and not to print it
systematically to standard output) on program load in libbpf.c.

But doing so, it only stores the content of attr.log_buf, while the
error string--resulting from a failed BPF syscall--is no more displayed
when the DEBUG_BPF flag is used in the Python script responsible for
converting and injecting the code.

This commit proposes a fix for this bug by printing the error message
(associated to the return value from the syscall) from the Python
caller, when all the following conditions are met:

- the syscall fails,
- the DEBUG_BPF flag has been provided, and
- log_buf is empty (has not been filled by kernel).

Note: when DEBUG_BPF is not provided, the error string is printed in the
C wrapper in libbpf.c (bpf_prog_load) anyway.

Fixes: 759029fe ("Add option for custom log string to bpf_prog_load")
Signed-off-by: Quentin Monnet <quentin.monnet@6wind.com>

Change kernel/user stacks order

Closes #559