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>

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>