fix python3 py_test_histogram failure

QoL improvements for inject

With python3 (specifically 3.6.3), py_test_histogram failed with:
  Traceback (most recent call last):
  File "./test_histogram.py", line 106, in test_multiple_key
    bucket_sort_fn=bucket_sort)
  File "/usr/lib/python3.6/site-packages/bcc/table.py", line 318, in print_log2_hist
    buckets = bucket_sort_fn(buckets)
  File "./test_histogram.py", line 98, in bucket_sort
    buckets.sort()
  AttributeError: 'dict_keys' object has no attribute 'sort'

The reason is for a dictionary tmp, tmp.keys() returns an object
of keys (a list) instead of the list itself for python3.
Using list(tmp.keys()) seems working for both python2 and python3.
Signed-off-by: Yonghong Song <yhs@fb.com>

fix test_libbcc failure with 4.15.

The test sleeps one second and expects the perf counter to
be one second or more. But in reality (probably esp. in VM
which I conducted my experiments), I mostly saw counters
between 0.9s - 1s and occasionally 0.8s - 0.9s.

So be a little bit conservative here when checking the
result.
Signed-off-by: Yonghong Song <yhs@fb.com>

filetop: probe vfs_read and vfs_write instead to fix inlining issue

Filetop was originally designed to probe __vfs_read and __vfs_write,
which are called by vfs_read and vfs_write, respectively. However,
__vfs_read and __vfs_write are at times inlined, leading to these
particular functions never actually being called. Since these functions
are never called, the probes are never hit, and so filetop ends up
registering zero READs and WRITEs.

This patch fixes the issue by attaching the probes to vfs_read and
vfs_write instead, which are guaranteed to be called during file reads
and writes.
Signed-off-by: Jazel Canseco <jcanseco@google.com>

Improve clear table API in C++

Add features/docs for inject (4.17)

bcc/syms: Fix shared library symbol lookup

Shared library addresses needed to be mapped what the address is expected in the
symbol table. The address offset of the running shared library may be different from
the one in the SO binary file. So we have to map it correctly in order for symbol
look up to work.

Often the address and file offset are the same so it works, however in Android this
is not the case a lot of times. Fix the issue by adjusting the offset with the
file offset from the ELF.

Test: stackcount 'sys_futex' -v

Before patch:
  ffffff800814bc14 sys_futex
  775d8e0db0       syscall
  775e149fe8       [unknown]
  775e14a598       [unknown]
  775e16a9e4       android::Parcel::validateReadData(unsigned long) const
  775e05d738       android::Thread::_threadLoop(void*)
  775d942470       __pthread_start(void*)
  775d8e54f8       __start_thread
    Binder:13353_5 [13353]

After patch:
  ffffff800814bc14 sys_futex
  78ba2e1db0       syscall
  78b97d4fe8       android::IPCThreadState::getAndExecuteCommand()
  78b97d5598       android::IPCThreadState::joinThreadPool(bool)
  78b97f59e4       [unknown]
  78b8dda738       android::Thread::_threadLoop(void*)
  78ba4ffbd0       android::AndroidRuntime::javaThreadShell(void*)
  78ba343470       __pthread_start(void*)
  78ba2e64f8       __start_thread
    Binder:14001_8 [14001]

Matches Perf output:
        ffffff800814bc14 sys_futex ([kernel.kallsyms])
                   1edb0 syscall (/system/lib64/libc.so)
                   45fe8 android::IPCThreadState::getAndExecuteCommand (/system/lib64/libbinder.so)
                   46598 android::IPCThreadState::joinThreadPool (/system/lib64/libbinder.so)
                   669e4 [unknown] (/system/lib64/libbinder.so)
                   10738 android::Thread::_threadLoop (/system/lib64/libutils.so)
                   7ebd0 android::AndroidRuntime::javaThreadShell (/system/lib64/libandroid_runtime.so)
                   80470 __pthread_start (/system/lib64/libc.so)
                   234f8 __start_thread (/system/lib64/libc.so)

Fixes: https://github.com/iovisor/bcc/issues/1628Signed-off-by: Joel Fernandes <joelaf@google.com>
Signed-off-by: Joel Fernandes <joel@linuxinternals.org>

Added -q option to execsnoop to quote individual arguments. 

moved quoting below argument pattern match, so that the pattern match happens on the unquoted argument

Added -q option to execsnoop to quote individual arguments. This helps when working with arguments that contain spaces.

fix compiler warning

The patch fixed the following compiler warnings:

  /home/yhs/work/bcc/src/cc/perf_reader.c: In function ‘read_data_head’:
  /home/yhs/work/bcc/src/cc/perf_reader.c:149:3: warning: dereferencing type-punned pointer will break strict-alias
  ing rules [-Wstrict-aliasing]
     uint64_t data_head = *((volatile uint64_t *)&perf_header->data_head);
     ^
  /home/yhs/work/bcc/src/cc/perf_reader.c: In function ‘read_data_head’:
  /home/yhs/work/bcc/src/cc/perf_reader.c:149:3: warning: dereferencing type-punned pointer will break strict-alias
  ing rules [-Wstrict-aliasing]
     uint64_t data_head = *((volatile uint64_t *)&perf_header->data_head);
     ^

Declaring perf_header as volatile type will force its member read from memory,
hence avoiding a forced type conversion.
Signed-off-by: Yonghong Song <yhs@fb.com>

fix some spelling errors

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

permit symbol resulotion for function with size 0

The issue comes up when I investigated issue #1641.
A func symbol defined in assembly code will be size of 0,
e.g., http://git.musl-libc.org/cgit/musl/tree/src/thread/x86_64/syscall_cp.s
symbol __cp_begin.
  .text
  .global __cp_begin
  .hidden __cp_begin
  ...
  __syscall_cp_asm:

  __cp_begin:
	mov (%rdi),%eax
	test %eax,%eax

and __cp_begin cannot be traced through bcc since
symbol resolution rejects any func symbol with size 0.

This patch removed size-must-not-zero restriction so that
the symbol like __cp_begin can be traced.
Command line: trace.py -p <pid> -U '<binary_path>:__cp_begin'
Signed-off-by: Yonghong Song <yhs@fb.com>

fix compilation error with latest llvm

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>