As discussed in https://github.com/iovisor/bcc/pull/1531
review comments.
Signed-off-by: Nathan Scott <nathans@redhat.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.  Formalise an -e/--ebpf option, and start
using it in several tools (more to come).
Signed-off-by: Nathan Scott <nathans@redhat.com>

The exception raised in the BPF class constructor assumed
that the "src_file" argument was used to pass eBPF code -
this is not the case for many of the tools scripts, which
tend to use "text".
Signed-off-by: Nathan Scott <nathans@redhat.com>

usdt: ignore location with incorrect probe virtual address

usdt: better handling for probes existing in multiple binary files

tools: syscount: add --errno=EPERM filter

Signed-off-by: Yonghong Song <yhs@fb.com>

Currently, for usdt, the commands where both a pid and a binary path
are specified are not well supported. For example,
```
funccount -p <pid> 'u:<binary_path>:probe'
```
will count `probe` occurances for all binary paths in `pid`, not just
`<binary_path>`. The command
```
argdist -p <pid> 'u:<binary_path>:probe():s64:arg1'
```
will also count `probe` occurances for all binary paths in `pid`
with my previous patch.

Furthermore, suppose user want to trace linker `setjmp` probe point
with command
```
trace.py -p <pid> 'u:/usr/lib64/ld-2.17.so:setjmp'
```
Without my previous patch, user will have incorrect results as both
`libc:setjmp` and `rtld:setjmp` exists and the bcc just picks the first
one which is `libc:setjmp`. My last patch will cause `enable_probe`
failures if in the same usdt context, two probes have the same
probe_name but different provider name.

To fix all these issues, this patch passes additional binary path
to the pid-based usdt context, so that only probes from that particular
binary will be added to the context. This solved all the above
mentioned issues.
Signed-off-by: Yonghong Song <yhs@fb.com>

Fixing issue #1515.

Currently, each usdt probe (provider, probe_name) can only
have locations from the single binary. It is possible that
USDT probes are defined in a header file which eventually causes
the same usdt probe having locations in several different
binary/shared_objects. In such cases, we are not able to attach
the same bpf program to all these locations.

This patch addresses this issue by defining each location to
be `bin_path + addr_offset` vs. previous `addr_offset` only.
This way, each internal Probe class can represent all locations
for the same (provider, probe_name) pair.

The `tplist.py` output is re-organized with the (provider, probe_name)
in the top level like below:
```
...
rtld:lll_futex_wake [sema 0x0]
  location #1 /usr/lib64/ld-2.17.so 0xaac8
    argument #1 8 unsigned bytes @ di
    argument #2 4 signed   bytes @ 1
    argument #3 4 signed   bytes @ 0
  location #2 /usr/lib64/ld-2.17.so 0xe9b9
    argument #1 8 unsigned bytes @ di
    argument #2 4 signed   bytes @ 1
    argument #3 4 signed   bytes @ 0
  location #3 /usr/lib64/ld-2.17.so 0xef3b
    argument #1 8 unsigned bytes @ di
    argument #2 4 signed   bytes @ 1
    argument #3 4 signed   bytes @ 0
...
```

Tested with the following commands
```
  tplist.py
  trace.py -p <pid> 'u::probe "arg1 = %d", arg1'
  trace.py u:<binary_path>:probe "arg1 = %d", arg1'
  argdist.py -p <pid> 'u::probe():s64:arg1'
  argdist.py -C 'u:<binary_path>:probe():s64:arg1'
  funccount.py -p <pid> 'u:<binary_path>:probe'
  funccount.py 'u:<binary_path>:probe'
```
Signed-off-by: Yonghong Song <yhs@fb.com>

Similar to `--filter` which reports all failing syscalls,
`--errno=ENOENT` reports syscalls failing with the specified errno value.

```
$ sudo bcc/tools/syscount.py -e ENOENT
Tracing syscalls, printing top 10... Ctrl+C to quit.
^C[12:07:13]
SYSCALL                   COUNT
open                        330
stat                        240
access                       63
execve                       22
readlink                      3
```

The patch fixed issue #1528. The linker ld.gold may generate
a probe with invalid virtual address if the section which the probe
relocates against is discarded.

Instead of failing, a simple checking is added such that
if the probe virtual address is less than the address of the first
instruction, print out a warning and ignore this probe.
Signed-off-by: Yonghong Song <yhs@fb.com>

Add new bpf_xdp_adjust_meta to docs/kernel-versions.md

Try use new API to create [k,u]probe with perf_event_open

Also adjust the order of helper functions.

New kernel API allows creating [k,u]probe with perf_event_open.
This patch tries to use the new API. If the new API doesn't work,
we fall back to old API.

bpf_detach_probe() looks up the event being removed. If the event
is not found, we skip the clean up procedure.
Signed-off-by: Song Liu <songliubraving@fb.com>

The new [k,u]probe API allows creating [k,u]probe together with
perf_event_open. This patch adds functions to use the new API.

Note: these new functions are not used until next patch, so this patch
doesn't change the behavior. The change is splitted into two patches
for cleaner review.
Signed-off-by: Song Liu <songliubraving@fb.com>

Increase bpf_attach_tracing_event buffer size

tcptracer: initialize skc_net variable

fix a verifier failure

when running with latest linus tree and net-next, the python test
tests/python/test_tracepoint.py failed with the following
symptoms:
```
......
 R0=map_value(id=0,off=0,ks=4,vs=64,imm=0) R6=map_value(id=0,off=0,ks=4,vs=64,imm=0) R7=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
34: (69) r1 = *(u16 *)(r7 +8)
35: (67) r1 <<= 48
36: (c7) r1 s>>= 48
37: (0f) r7 += r1
math between ctx pointer and register with unbounded min value is not allowed
......
```

The reason of failure is due to added tightening in verifier introduced by
the following commit:
```
commit f4be569a429987343e3f424d3854b3622ffae436
Author: Alexei Starovoitov <ast@kernel.org>
Date: Mon Dec 18 20:12:00 2017 -0800

bpf: fix integer overflows
......

```

The patch changes `offset` type in `ctx + offset` from signed to
unsigned so that we do not have `unbounded min value` so the
test trace_tracepoint.py can pass.
Signed-off-by: Yonghong Song <yhs@fb.com>

sync bpf compat headers with latest net-next

Signed-off-by: Yonghong Song <yhs@fb.com>

fix runqlen.py with 4.15 kernel

The following kernel commit changes linux_src:kernel/sched/sched.h
struct cfs_rq structure:

```
commit 1ea6c46a23f1213d1972bfae220db5c165e27bba
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Sat May 6 15:59:54 2017 +0200

    sched/fair: Propagate an effective runnable_load_avg

    The load balancer uses runnable_load_avg as load indicator. For
    !cgroup this is:

      runnable_load_avg = \Sum se->avg.load_avg ; where se->on_rq

    That is, a direct sum of all runnable tasks on that runqueue. As
    opposed to load_avg, which is a sum of all tasks on the runqueue,
    which includes a blocked component.
...
```

The commit is in kernel 4.15 release and will make current
runqlen.py internal cfs_rq_partial structure not syncing with the kernel one.
As a result, runqlen.py will produce incorrect results on 4.15.

This patch attempts to solve this issue by compiling a bpf program,
which accesses one of fields introduced by the above commit.
The successful compilation will indicate that we should amend
the cfs_rq_partial structure.
Signed-off-by: Yonghong Song <yhs@fb.com>

tcplife: add tcp:tcp_set_state tracepoint support

fix a compilation error with latest llvm/clang trunk

bcc build with latest llvm/clang trunk failed with the
below error:
......
[ 35%] Built target api-static
/home/yhs/work/bcc/src/cc/frontends/clang/tp_frontend_action.cc: In member function ‘bool ebpf::TracepointTypeVisitor::Visit
FunctionDecl(clang::FunctionDecl*)’:
/home/yhs/work/bcc/src/cc/frontends/clang/tp_frontend_action.cc:163:60: error: no matching function for call to ‘clang::Qual
Type::getAsString(clang::SplitQualType)’
         auto type_name = QualType::getAsString(type.split());
                                                            ^
......

The error is caused by the below clang commit:
commit fcc28fd8cc8139cf1e4763459447880768579d8e
Author: Aaron Ballman <aaron@aaronballman.com>
Date:   Thu Dec 21 21:42:42 2017 +0000

    Re-commit r321223, which adds a printing policy to the ASTDumper.
......
-  std::string getAsString() const {
-    return getAsString(split());
+  static std::string getAsString(SplitQualType split,
+                                 const PrintingPolicy &Policy) {
+    return getAsString(split.Ty, split.Quals, Policy);
   }
+  static std::string getAsString(const Type *ty, Qualifiers qs,
+                                 const PrintingPolicy &Policy);

-  static std::string getAsString(SplitQualType split) {
-    return getAsString(split.Ty, split.Quals);
-  }
-
-  static std::string getAsString(const Type *ty, Qualifiers qs);
-
+  std::string getAsString() const;
   std::string getAsString(const PrintingPolicy &Policy) const;
......

The signature of static function getAsString(), which is used
in src/cc/frontends/clang/tp_frontend_action.cc, got changed,
and this caused the compilation error.

The patch chooses a different way to get type_name which works
for llvm 4.0 to 6.0 (tested).
Signed-off-by: Yonghong Song <yhs@fb.com>

CentOS 6 support

fix build issue for llvm 5.0.1

Fix issue #1502.
A few cmake version checking greater than 5 includes 5.0.1
which results in compilation failure. Change version checking
to explicitly equal to or greater than version 6.
Signed-off-by: Yonghong Song <yhs@fb.com>

ucalls: convert bytes to str

Fix incorrect lost_cb type in Python

Fix and improvement for perf_reader's lost_cb