Fix 'test_debuginfo' from failing if a kernel symbol has multiple aliases

Update LINKS.md

The first symbol from /proc/kallsyms is read by 'test_debuginfo'
and the name obtained here is compared against the name obtained
from the BPF.ksym() library call. In some architectures such as
powerpc64le, a kernel symbol may have multiple aliases that refer
to the same address. So, to avoid the test from failing, we need
to compare the name returned by BPF.ksym() against all possible
aliases for the given address in /proc/kallsyms and look for a
match.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

Signed-off-by: Gary Lin <glin@suse.com>

Signed-off-by: Colin Ian King <colin.king@canonical.com>

nfsdist: trace NFS operation latency distribution, similar to the other *dist tools.

Fix for incorrect tool arguments in the man pages

Improve string buffer checking on uprobe attach and detach

annotate program tag

Do not create instance for kprobe

Fix for bug in lesson 4 of the Python developer tutorial

during debug of production systems it's difficult to trace back
the kernel reported 'bpf_prog_4985bb0bd6c69631' symbols to the source code
of the program, hence teach bcc to store the main function source
in the /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/ directory.

This program tag is stable. Every time the script is called the tag
will be the same unless source code of the program changes.
During active development of bcc scripts the /var/tmp/bcc/ dir can
get a bunch of stale tags. The users have to trim that dir manually.

Python scripts can be modified to use this feature too, but probably
need to be gated by the flag. For c++ api I think it makes sense
to store the source code always, since the cost is minimal and
c++ api is used by long running services.

Example:
$ ./examples/cpp/LLCStat
$ ls -l /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/
total 16
-rw-r--r--. 1 root root 226 Sep  1 17:30 on_cache_miss.c
-rw-r--r--. 1 root root 487 Sep  1 17:30 on_cache_miss.rewritten.c
-rw-r--r--. 1 root root 224 Sep  1 17:30 on_cache_ref.c
-rw-r--r--. 1 root root 484 Sep  1 17:30 on_cache_ref.rewritten.c

Note that there are two .c files there, since two different
bpf programs have exactly the same bytecode hence same prog_tag.

$ cat /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/on_cache_miss.c
int on_cache_miss(struct bpf_perf_event_data *ctx) {
    struct event_t key = {};
    get_key(&key);

    u64 zero = 0, *val;
    val = miss_count.lookup_or_init(&key, &zero);
...
Signed-off-by: Alexei Starovoitov <ast@fb.com>

bpf_obj_get_info() to retreive prog_tag from the kernel based on prog_fd (kernel 4.13+)
bpf_prog_compute_tag() to compute prog_tag from a set of bpf_insns (kernel independent)
bpf_prog_get_tag() to retrieve prog_tag from /proc/pid/fdinfo/fd (kernel 4.10+)
Signed-off-by: Alexei Starovoitov <ast@fb.com>

docs: update features list

examples: fixed http_filter example

Loop unrolling wasn't happening because of variable upper
bound. Making it const fixes the problem.

Tested with 4.13.0-rc6 on fedora 26

Mention the smoke tests for new tool contributions

examples: fix vlan_learning example

* Initial commit of nfsslower, tracking NFS4_READ, NFS4_WRITE and NFS4_OPEN

* Added in documentation, examples, support for csv and tracing for GETATTR

* Added in man pages, READM mods and example file, to comply with
https://github.com/samuelnair/bcc/blob/master/CONTRIBUTING-SCRIPTS.md

* Changes to address comments from @brendangregg and a small bug regarding
the output header not being printed when tracing all NFS operations

* Added nfsslower to the correct alphabetical postion

* Addressing Sasha's comments. I appreciate the thoroughness of the review

* Added test case for nfsslower and an extra function to check if the NFS kernel
module is loaded

Following the release of kernel 4.13.

We probably have a couple of tools where we forgot about this already.
Make sure we don't forget again...

BPF_HASH declaration fixed.

* stackcount: add -K and -U

* stackcount: add -D for duration

* stackcount: add -f for folded output

Also added a warning if the length is exceeded

zfs tools fix for zpl_read/zpl_write removal

Performing the update before lookup incurs an extra spinlock in the
kernel, which hurts performance. Reorder the code and increment to 1.
The memset is there I believe due to some type mismatch warnings, so I'm
leaving as is rather than doing a direct assign to 1. The resulting code
is optimized away anyway.

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

The bug does not show up in my previous test probably because
I did not clean up the build directory and did not have a clean cmake.

In gcc 4.8.5 environment where -no-pie is not supported,
a clean cmake will trigger the issue as subsequent other
cxx compile test will fail due to additional -no-pie flag.

The fix is to reset the CMAKE_REQUIRED_FLAGS to its previous value
after the specific test.
Signed-off-by: Yonghong Song <yhs@fb.com>