Signed-off-by: Geneviève Bastien <gbastien@versatic.net>

`trace.py` parses a probe using the colon as a separator.  As a result, it
fails to create a uprobe for binary/library with a filename containing colons.

This diff fixes that issue with `trace.py`.  It requires a kernel with
https://lkml.org/lkml/2017/1/13/585 merged to work properly, otherwise
`trace.py` still fails for create uprobes.

* memleak: handle libc allocation functions other than malloc

* memleak: use tracepoints to track kernel allocations

* memleak: add combined-only mode

With large number of outstanding allocations, amount of data passed from
kernel becomes large, which slows everything down.

This patch calculates allocation statistics inside kernel, allowing user-
space part to pull combined statistics data only, thus significantly
reducing amount of passed data.

* memleak: increase hashtable capacities

There are a lot of allocations happen in kernel. Default values are not
enough to keep up.

* test: add a test for the memleak tool

This sample contains:
    - A library with an operation that uses usdt probes.
    - A console application that calls the operation.
    - Scripts to trace the latency of the operation.
    - Corresponding cmake files.

And fix a typo: direct_action -> direct-action

The macro _GNU_SOURCE should be defined to pick up the function
declaration for setns.  Fixes build warning:

"src/cc/libbpf.c:482:7: warning: implicit declaration of
 function 'setns' [-Wimplicit-function-declaration]
   if (setns(target_fd, CLONE_NEWNS)) {"
Signed-off-by: Colin Ian King <colin.king@canonical.com>

Fix bcc.lua build issue in Ubuntu 17.04

Cleanup the `strncmp` code and add a few more ignored map names

In fc25 box, gcc6.3.1 is configured with pie default off.
Here, pie stands for position independent execution.

In ubuntu 17.04, gcc6.3.0, however, is configured with
pie default on. The gcc driver automatically adds -pie
to the linker options.

Since bcc.lua build needs pie off, previously, -fno-pie
is passed to the compiler. -fno-pie is a gcc option
impacting the code generation and it didn't
negate the -pie option in the linker. The correct way
seems to use gcc linker option -no-pie which can
successfully cancel the default -pie in the linker.
Signed-off-by: Yonghong Song <yhs@fb.com>

Treat strings as bytes. This is independent of the larger refactor
(#1139) from which it is cherry-picked)
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

The issue is caused by the following clang change on 5.0:
https://reviews.llvm.org/D28404

Basically, at -O0, unless always inlining is specified, a
function will be marked as optnone and noinline.

This causes two kinds of issues: (1). optnone will generate
suboptimal code with heavy stack use and this high likely can
cause verifier failure; and (2). even if user mark all his/her
defined functions in bpf program as always inlining, some
functions in linux header files are not marked as always inline
and hence will be marked as noinline instead, ultimately
causing llvm complaining about global function reference.

This patch bumps the clang optimization level to -O2.
This should work with older versions of llvm as well.
Signed-off-by: Yonghong Song <yhs@fb.com>

Update the installation instructions for Fedora

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

cnb@ubuntu-14:~/iovisor/bcc/build$ make
[  6%] Built target clang_frontend
[  9%] Built target bpf-static
[ 16%] Built target bcc-loader-static
[ 30%] Built target b_frontend
[ 47%] Built target bcc-static
[ 48%] Built target CPUDistribution
[ 50%] Built target FollyRequestContextSwitch
[ 51%] Built target HelloWorld
[ 52%] Built target LLCStat
[ 54%] Built target RandomRead
[ 55%] Built target RecordMySQLQuery
[ 56%] Built target TCPSendStack
[ 80%] Built target bcc-shared
[ 83%] Built target bpf-shared
[ 84%] Built target bcc_py
Linking C executable bcc-lua
cc: error: unrecognized command line option â-no-pieâ
make[2]: *** [src/lua/bcc-lua] Error 1
make[1]: *** [src/lua/CMakeFiles/bcc-lua.dir/all] Error

option is called -fno-pie

Fixes #782. Solution taken verbatim from @jepio here:

https://github.com/iovisor/bcc/issues/782#issuecomment-259075010

I ran into the same issue attempting to compile from source on
a fresh Ubuntu 16.10/Yakkety host:

Linking C executable bcc-lua
/usr/bin/ld: libluajit-5.1.a(ljamalg.o): relocation R_X86_64_32S
    against `.rodata' can not be used when making a shared object;
    recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

Build succeeded after patch was applied.

o This is caused by my ignorant error in previous usdt change.
  Obviously, I need to store into pointer address in order to
  propagate value back to caller.
o Thanks Tetsuo Handa pointing this out.
Signed-off-by: Yonghong Song <yhs@fb.com>

  o The sample application covers different aspects
    of usdt rewriter code generation:
    - const
    - *(ctx + offset)
    - use bpf_probe_read to get trace data
    - the switch in ctx->ip if the same probe
      is triggered in multiple .text locations.
  o folly (https://github.com/facebook/folly/) tracing
    header files are pulled into python test directory and
    used to produce USDT probes.
Signed-off-by: Yonghong Song <yhs@fb.com>

Force udst ctx->#reg load to be volatile

Add linux/sched.h to list of libbpf.c includes

This should hopefully fix compile errors on some ubuntu systems.

Also, reorders the includes according to clang-format
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Break the c++ dependency in libbpf.c, and turn it into a separate lib
from cmake point of view.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

This moves ProcMountNS[Guard] classes to a separate header file and
implementation. The goal will be to use these more directly in libbpf.c
without creating a circular dependency.
Removed the friend class statements and exposed a few public getters instead.
Slightly changed the implementation in ProcMountNS constructor to avoid
a few error cases and the use of snprintf.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

This is related to issue #1133. Compiler sometimes
generates code patterns likes:
     r1 = ctx + 96
     goto next
   here:
     r1 = ctx + 48
   next:
     r3 = load (r1 + 0)
Verifier will fail for such cases as r1 is marked
as "unknown" at the time of load.

The previous workaround is to add volatile attribute
to the store like
   *(volatile u64 *)&dest = ctx->bx
The hope is to force ctx related load in-place since
its value is needed for store.

Unfortunately, this does not always work and compiler
still has freedom to merge different ctx loads at the
same time honoring the volatile &dest. In USDT generated
code, different branches of &dest are the same.

This patch directly make ctx->bx itself as a volatile load:
  *(volatile u64 *)&ctx->bx
This seems working as compiler stops playing around
the address pointing to a volatile data.
Signed-off-by: Yonghong Song <yhs@fb.com>