Add extra_flag option to bpf_attach_perf_event_raw

The bpf_attach_perf_event_raw API is designed to provide maximum
flexibility for people to use advanced features of Kernel Perf Events
with BPF. Some times specifying flags is neccesary, such as if we want
to use `PERF_FLAG_PID_CGROUP` to profile a container. This commit adds
`extra_flag` option to C and C++ interface

link with bpf-static library for bps

* Add stream debug output for C++ USDT class

This commit adds ability to output USDT class debug message to iostream

* USDT::init() as public function

It would be nice for users be able to call init() and see if the probe
exists / well-formatted before sending them to BPF instance

the issue is reported at #1759.

bps does not need any C++ library functions in bcc.
It only needs libbpf. So link it with bpf-static instead
of bcc-static. This avoids pulling in any C++ module/symbolization/usdt
functions and llvm libraries.

On my local box, the binary size is reduced from ~60MB to 44KB.
Signed-off-by: Yonghong Song <yhs@fb.com>

Currently do calculate the syscall prefix in BPF::init, which requires
loading kallsyms etc. But a lot of times the functionality will not be
used. This commit changes that we only calculate the syscall prefix the
first time we call get_syscall_fnname

Also change to use the KSym class directly for better destruct
production

fix get_kprobe_functions

and add `from __future__ import print_function` where needed for Python3
print semantics in Python2

Fix issue #1747.

In commit #1647, we excluded all symbols outside [_stext, _etext].
This is incorrect as it excluded module symbols as well.

This patch changed the algorithm to only skip symbols
in init sections [__init_begin, __init_end].
Signed-off-by: Yonghong Song <yhs@fb.com>

- Fix a crash in the python binding when trying to open a perf buffer
    in python < 3.6
- See https://github.com/iovisor/bcc/issues/1744

This PR fixes the encoding issue in Python3 by converting the argument passed to `find` to a bytearray.

Run queue latency does not make much sense for idle `swapper` threads.

The same happens in `perf sched`:

* https://github.com/torvalds/linux/blob/v4.14/tools/perf/builtin-sched.c

```c
    /*
     * Ignore idle threads:
     */
    if (!strcmp(thread__comm_str(work_list->thread), "swapper"))
        return;
```

```c
static bool is_idle_sample(struct perf_sample *sample,
	       struct perf_evsel *evsel)
{
    /* pid 0 == swapper == idle task */
    if (strcmp(perf_evsel__name(evsel), "sched:sched_switch") == 0)
        return perf_evsel__intval(evsel, sample, "prev_pid") == 0;

    return sample->pid == 0;
}
```

* Add runqslower tool

* Remove mentions of obsolete enqueue_task_* in tools/runq*

* Use u32 for pid field in runqslower

* Trace all external pointers going through a first map

Currently, MapVisitor only detects maps with external pointers as
values if the value was directly passed from a function's argument.
For example, in the following, the rewriter is currently unable to
detect currsock has an external pointer as value because an
intermediate variable is used instead of passing directly sk as the
map's value.

    int test(struct pt_regs *ctx, struct sock *sk) {
        u32 pid = bpf_get_current_pid_tgid();
        struct sock **skp = &sk;
        currsock.update(&pid, skp);
        return 0;
    };

With this commit, MapVisitor is able to trace any external pointer
derived from the function's argument and used as a map value. This
commit breaks the ProbeVisitor traversal in two distinct traversals.
The first rewrites dereferences of external pointers originating
from function's arguments and helpers, while the second rewrites only
dereferences of external pointers passed through maps.
Maps with external pointers as values are identified between the two
ProbeVisitor traversals.

* New tests for external pointers passed through maps

test_ext_ptr_maps_reverse ensures dereferences are correctly replaced
even if the update happens after the lookup (in the order of
MapVisitor traversal).
test_ext_ptr_maps_indirect ensures the rewriter is able to trace
external pointers used as map values even if using an intermediate
variable.

* Fix USDT probes arguments' encoding in Python3

Running `trace` on a binary's USDT while fetching some arguments (
`sudo python3 trace.py -p $(pidof ruby) 'u:ruby:array__create "%d",
arg1'`) fails with `argument 2: <class 'TypeError'>: wrong type`.

This PR fixes the encoding of the USDT probe name in
udst.py `get_probe_arg_ctype` function. I've tested this works on Python 2 too.

Link to article on how Circonus uses bcc

old/tools: Diverse fixes

Fix dereference replacements for structure members

Dereferences of structure members pointing to external addresses are
now correctly recognized and replaced by bpf_probe_read calls by the
rewriter.

Currently, if a structure member is assigned an external pointer
(pointer to kernel address), the pointer to the structure is marked
as external instead of the structure member. This issue affects all
uses of structures with pointers to external addresses. This commit
fixes it by marking the structure member as external.

Fix "'ArgString' object has no attribute 'rfind'" error

os.path.dirname expects a string.

Fix bpf_trace_printk() for big-endian targets

The format string for bpf_trace_printk() gets garbled during the
conversion of the LLVM IR code to the corresponding BPF object.
This happens because bcc explicitly sets the data layout of the
module to 'e-m:e-p:64:64-i64:64-n32:64-S128' which is valid for
little-endian targets only. If the arch is set to 'bpf', LLVM
selects the correct data layout automatically and there is no
need to set this explicitly.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Reported-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Fixes: #1723

Remove duplicate ebpf program load in tools/runqlen.py

fix lua compilation issue with latest clang/llvm 7.0

fix compilation error with latest llvm

The clang commit https://reviews.llvm.org/rL331155
changed the clang::SourceManager function prototype
   SourceRange getExpansionRange(SourceRange Range)
to
   CharSourceRange getExpansionRange(SourceRange Range)
and caused the following compilation failure:

  /home/yhs/work/bcc/src/cc/frontends/clang/b_frontend_action.cc:
  In member function ‘clang::SourceRange ebpf::ProbeVisitor::expansionRange(clang::SourceRange)’:
  /home/yhs/work/bcc/src/cc/frontends/clang/b_frontend_action.cc:267:58:
  error: could not convert ‘(&(&((ebpf::ProbeVisitor *)this)->ebpf::ProbeVisitor::rewriter_)
         ->clang::Rewriter::getSourceMgr())->clang::SourceManager::getExpansionRange(range)’
  from ‘clang::CharSourceRange’ to ‘clang::SourceRange’
     return rewriter_.getSourceMgr().getExpansionRange(range);
                                                            ^
  ...

It is hard to find a compatible change which works
for both old llvm and the latest change. So this patch
just fixed the problem for clang 7.0.0 and the old code
is used for clang 6.x and lower.
Signed-off-by: Yonghong Song <yhs@fb.com>

Detect external pointers from context argument

The bcc rewriter is currently unable to detect external pointers
(i.e., to a memory address that requires calls to bpf_probe_read) if
they are not declared as arguments, e.g., if they are retrieved
through the context argument.
For example, although the two following examples translate to the
same C code in the end (the bcc rewriter translates the first into
the second), the sk pointer is recognized as an external pointer only
in the first example.

int test1(struct pt_regs *ctx, struct sock *sk) {
    // sk is correctly recognized as an external pointer.
}
int test2(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)ctx->di;
    // sk is not recognized as an external pointer.
}

This commit fixes that by detecting member dereferences of the
context argument (i.e., the first argument of externally visible
functions). It also works for the TRACEPOINT_PROBE macro.

Commit 46ebd9ef ("fix compilation with latest clang/llvm 7.0")
tried to fix a compilation introduced with latest clang change.
It did not fix the lua compilation issue since unfortunately
my bcc environment did not have lua setup properly for that commit.

This commit intends to fix for lua compilation issue as well.
The intermediate static library bcc-lua-static is removed and
now bcc-lua-static is just a list of static libraries used
for final linking to produce bcc-lua. This way, we do not
need the special linker flags like -Wl,--whole-archive and
-Wl,--no-whole-archive. The bcc-static and bcc-shared libraries
did not change since they will be installed and may be used
by the application.

Tested on FC27 based system, with the workaround in issue #1685,
all tests passed.

Fixes: 46ebd9ef ("fix compilation with latest clang/llvm 7.0")
Signed-off-by: Yonghong Song <yhs@fb.com>