The latest llvm (7.0) changed the interface for
IRBuilder/CreateMemCpy as in https://reviews.llvm.org/rL328317.
This caused the compilation error like below:

  [ 30%] Built target bcc-loader-static
  /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc: In member function ‘virtual ebpf::StatusTuple
  ebpf::cc::CodegenLLVM::visit_string_expr_node(ebpf::cc::StringExprNode*)’:
  /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc:428:52: error: no matching function for call t$
   ‘llvm::IRBuilder<>::CreateMemCpy(llvm::Value*&, llvm::Value*&, std::basic_string<char>::size_type, $
  nt)’
     B.CreateMemCpy(ptr, global, n->val_.size() + 1, 1);
                                                    ^
  /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc:428:52: note: candidates are:
  In file included from /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc:31:0:
  /home/yhs/work/llvm/build/install/include/llvm/IR/IRBuilder.h:422:13: note: llvm::CallInst* llvm::IR$
  uilderBase::CreateMemCpy(llvm::Value*, unsigned int, llvm::Value*, unsigned int, uint64_t, bool, llv$
  ::MDNode*, llvm::MDNode*, llvm::MDNode*, llvm::MDNode*)
     CallInst *CreateMemCpy(Value *Dst, unsigned DstAlign, Value *Src,
             ^

Now the interfaces between 7.0 and 6.0 CreateMemCpy
are completely disjoint and we are not able to find a common
interface suitable for both.

This patch fixed the issue by separating two cases based on
llvm compiler version.
Signed-off-by: Yonghong Song <yhs@fb.com>

Building from source on openSUSE Tumbleweed requires the clang-devel …

sync bpf compat headers with latest net-next, update doc for helpers

Return number of CPUs with data for BPFPerfBufferTable::poll()

Signed-off-by: Nirmoy Das <ndas@suse.de>

- Update links in doc (make them point from net-next to linux, when
  relevant).
- Fix kernel version for bpf_msg_*() helpers, 4.17 instead of 4.16, in
  doc and in header.
- Add helper bpf_bind() to documentation and headers.
- Synchronise helpers with latest net-next.

tools/cachetop: match bpf.ksym() with bytes arrays

tools/syscount: convert syscall and process names to bytes array

bpf.ksym() now returns a bytes array, and python3 would issue TypeError
when matching the string.
Signed-off-by: Gary Lin <glin@suse.com>

subprocess.check_output() returns a bytes array in python3 while it
returns str in python2. To improve the compatibility, convert the
related fields to bytes arrays and print them with printb().
Signed-off-by: Gary Lin <glin@suse.com>

Update INSTALL.md

Add `libfl-dev` to the dependencies on debian to prevent the following error:
```
[ 16%] Building CXX object src/cc/frontends/b/CMakeFiles/b_frontend.dir/loader.cc.o
In file included from /root/bcc/src/cc/frontends/b/parser.h:21:0,
                 from /root/bcc/src/cc/frontends/b/loader.cc:17:
/root/bcc/src/cc/frontends/b/lexer.h:22:23: fatal error: FlexLexer.h: No such file or directory
 #include <FlexLexer.h>
                       ^
compilation terminated.
```

Two minor fixes on Stack-trace table

avoid symbol demangling if the symbol is not a mangled symbol

Fix issue #1641

The bcc user space stack is not printed out properly.

From https://en.wikipedia.org/wiki/Name_mangling,
all mangled symbols begin with _Z, and an identifier
beginning with an underscore followed by a capital is
a reserved identifier in C, so conflict with user identifiers
is avoided.

Further, from the llvm demangle code
https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa_demangle.cpp
The demangled name has the following specification:
    <mangled-name> ::= _Z <encoding>
                   ::= <type>
    extension      ::= ___Z <encoding> _block_invoke
    extension      ::= ___Z <encoding> _block_invoke<decimal-digit>+
    extension      ::= ___Z <encoding> _block_invoke_<decimal-digit>+

In the issue #1641, the function name are "f" and "g", which is demangled
to type "float" and "__float128", according to the above implementation.

In bcc case, we only care about functions, so only do demangling
for symbols starting with _Z or ___Z.
Signed-off-by: Yonghong Song <yhs@fb.com>

skip kprobe functions outside normal text section

Fix spelling mistake in raised Exception

Add new targeted error injection tool

scripts: check virtual_list.h's list of helpers

Fix issue #1634.

When kernel is about to attach a kprobe, the following functions
are called:
  register_kprobe
    check_kprobe_address_safe
      kernel_text_address
        core_kernel_text

In core_kernel_text, we have:
        if (addr >= (unsigned long)_stext &&
            addr < (unsigned long)_etext)
                return 1;

Basically, any address outside of [_stext, _etext] will
be rejected.

The functions marked as __init are outside [_stext, _etext].
That is why vfs_caches_init_early and vfs_caches_init
are rejected by trace_kprobe.
Given a regex, this patch avoided attaching these functions
if their func addresses are outside [_stext, _etext] range.
Signed-off-by: Yonghong Song <yhs@fb.com>

sync bpf compat headers with latest net-next

add an example of accessing an externally created map in C++

Some application may need to access a pinned map which is not
created by bcc. This example shows how to incorporate such
maps with C++ APIs.

Basically, the application needs to create a TableStorage and
pre-populate it with pinned map before calling BPF constructor.
The bpf program defines this pinned map as an "extern" map.
Signed-off-by: Yonghong Song <yhs@fb.com>

add the tcpstates tool

docs: add latest eBPF helpers to features list

This patch extends the PYTHON_CMD cmake variable to allow a list of
Python binaries and installs the bcc Python bindings for each Python
installation. The Debian control files are updated to generate bindings
for Python 2 and Python 3. Compiled Python files are excluded from the
Debian packages.
Signed-off-by: Andreas Gerstmayr <andreas@gerstmayr.me>