solisten.py maintenance

Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>

Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>

Make 'tools/wakeuptime' use stack maps

This moves the original wakeuptime script that uses
manual stack walking to the old tools directory.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

This updates the manpage and examples for 'tools/wakeuptime'
so that they include descriptions of the new arguments.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

This fixes 'test_tools_smoke' from failing on systems
running linux < 4.6 because of the wakeuptime script.
This script uses the bpf stack maps feature which is
available only for linux 4.6+. To avoid this, we skip
running it if the minimum kernel version requirement
is not met.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

Fix 'test_tools_smoke' from failing due to timeout

This modifies 'tools/wakeuptime' to include a filter
in offcpu() for capturing data only for a given pid
or for user threads only.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

This fixes 'test_tools_smoke' from failing if ucalls and
vfscount need more time to terminate than the specified
timeout duration when running on certain architectures
such as powerpc. To avoid this, we increase the timeout
duration.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

This modifies 'tools/wakeuptime' to use the stack maps feature.
Rather than using manual, depth-limited stack walking with some
architecture-specific code, using stack maps makes the script
usable across different architectures. This also adds command
line arguments to let the user to set the minimum and maximum
amount of time in microseconds over which traces are stored.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>

use user-provided log_level in bpf_prog_load

For the case where user provided a log buffer, the
user provided log_level is already been used.

For the case where user provided a log_level and bcc
needs to allocate buffer, the log_level is fixed to 1.
Use user provided log level instead.
Signed-off-by: Yonghong Song <yhs@fb.com>

Move BCC debug options to a installed header file

Kernel Commit 29e48ce87f1e ("task_struct: Allow randomized layout")
(https://patchwork.kernel.org/patch/9797817/)
permits to randomize a section of kernel task_struct data
structure. This only takes effect when CONFIG_GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT are set.

When randomization does not happen, an anonymous struct
is introduced in task_struct data structure by gcc when compiling
the kernel. To make field offset compatible, task_struct will
have the same anonymous struct. The patch is at
http://www.spinics.net/lists/kernel/msg2644958.html.
Otherwise, bpf program may get wrong data from the kernel.

Currently, bcc bpf_probe_read rewriter does not support
anonymous struct/union. For example, with the above
compiler-clang.h patch, examples/tracing/task_switch.py
will have the following error:
  /virtual/main.c:16:18: error: internal error: opLoc is invalid while preparing probe rewrite
    key.prev_pid = prev->pid;
                   ^

For anonymous structure, opcode source location ("->") is not available
and hence the above failure. We could use memberLoc ("pid") which is
available for anonymous struct/union. For example, for
  struct sock *skp; ...; u32 saddr = skp->__sk_common.skc_rcv_saddr;
The old way for bpf_probe_read rewrite:
  bpf_probe_read(&_val, sizeof(_val), (u64)skp + offsetof(struct sock, __sk_common.skc_rcv_saddr));
The new way:
  bpf_probe_read(&_val, sizeof(_val), (u64)&skp->__sk_common.skc_rcv_saddr);

The new way is similar to what typical bpf programs may do manually.
Signed-off-by: Yonghong Song <yhs@fb.com>

When BPFModule finalized the module, it set UseOrcMCJITReplacement to
true to use OrcJIT for ExecutionEngine. However, this never worked.
First, in clang_libs.cmake, mcjit is in the library list instead of
orcjit, so ExecutionEngine always fell back to MCJIT.
Second, even if OrcJIT was linked correctly, it actually broke bcc.
For OrcJIT, finalizeObject() is just an empty function. The code
generation is delayed till getPointerToFunction() or runFunction(), so
the current implementation of BPFModule won't work for OrcJIT.

This bug was covered when using the separate LLVM share libraries. If
the system builds LLVM into an unified share library, then OrcJIT will
be used and bcc would fail to generate BPF bytecodes without any
warning.
Signed-off-by: Gary Lin <glin@suse.com>

Add flag to enable verifier log_level 2

Unify DEBUG_BPF logging to be handled in libbpf

Consistently use spaces in C in Python tutorial

In fc26, kernel config enables CONFIG_FORTIFY_SOURCE
in 4.13 kernel. This is not available in fc25.
This config is used to detect overflows of buffers in common string
and memory functions where the compiler can determine and
validate the buffer sizes.

When enabled, this option provides an implementation (body)
for certain string function. For example, in
/lib/modules/4.13.10-200.fc26.x86_64/build/include/linux/string.h,
you can find
...
extern void * memcpy(void *,const void *,__kernel_size_t);
...
__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
{
        size_t p_size = __builtin_object_size(p, 0);
        size_t q_size = __builtin_object_size(q, 0);
        if (__builtin_constant_p(size)) {
                if (p_size < size)
                        __write_overflow();
                if (q_size < size)
                        __read_overflow2();
        }
        if (p_size < size || q_size < size)
                fortify_panic(__func__);
        return __builtin_memcpy(p, q, size);
}

In current clang frontend, we treat an external function with function body
as a rewritable target. We also assume the declaration of this external function,
if body is present, must have named arguments. This is largely true
for functions in bpf program file/text itself as these external functions often
do not have declarations.

We should not try to rewrite string/memory functions exposed by
CONFIG_FORTIFY_SOURCE. This patch adds restriction for rewritable function
only if the corresponding file is the main file with bpf program itself.

I discovered that it is possible file name is empty for tracepoint
functions, e.g.,
  TRACEPOINT_PROBE(irq, softirq_entry)
The reason could be function name itself is derived from helpers.h while
function declaration/body is in the main file after macro expansion.
Note that function name is still correctly derived by the compiler.
Signed-off-by: Yonghong Song <yhs@fb.com>

Fix Module display for unreadable Modules

softirqs: focus CPU as disector

Fix minor compilation issue in bps

Linter cleanups

bpf: make test py_test_tools_smoke pass on arm64

Add usdt support for ARM64

mdflush: fix for Linux 4.14

Trace external pointers through maps

Fix exception handling in python3

Changes include:
  . Add PT_REGS_FP to access base(FP) register in x64
  . Use macros, intead of directly ctx-><reg_name>
    in a few places
  . Let userspace fill in the value of PAGE_SIZE.
    Otherwise, arm64 needs additional headers to
    get this value for kernel.
  . In tools/wakeuptime.py, arm64 and x86_64 have
    the same stack walker mechanism. But they
    have different symbol/macro to represent
    kernel start address.
With these changes, the test py_test_tools_smoke
can pass on arm64.
Signed-off-by: Yonghong Song <yhs@fb.com>

Specifically the following argument patterns will be
supported:
```
   [-]<size>@<value>
   [-]<size>@<reg>
   [-]<size>@[<reg>]
   [-]<size>@[<reg>,<offset>]
```

I did not use std regex library as the old gcc (e.g. 4.8.5)
does not have a good support for it.
Signed-off-by: Yonghong Song <yhs@fb.com>