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>

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.

fix compilation with latest clang/llvm 7.0

profile: update --stack-storage-size default value in help message

The bcc build with latest clang/llvm 7.0 has the following
compilation error:

 /home/yhs/work/llvm/build/install/lib/libclangCodeGen.a(CodeGenAction.cpp.o):
  In function `clang::BackendConsumer::Initialize(clang::ASTContext&)':
  CodeGenAction.cpp:(.text._ZN5clang15BackendConsumer10InitializeERNS_10ASTContextE[_ZN5clang15BackendConsumer10InitializeERNS_10ASTContextE]+0xc): undefined reference to `clang::FrontendTimesIsEnabled'
 ...

The latest clang defined clang::FrontendTimesIsEnabled in
libclangFrontend.a and used in libclangCodeGen.a.

Due to the library order specified in clang_libs.cmake:
  # order is important
  set(clang_libs
    ${libclangFrontend}
    ...
    ${libclangCodeGen}
and the fact clang_libs here is used to build bcc-static,
the definition of clang::FrontendTimesIsEnabled is dropped
since nobody used it before the definition is checked by the compiler.

The fix here is to keep all the definitions/uses for clang_libs/llvm_libs
when buildint static library.

Tested on clang 4.0, 5.0, 6.0 and latest 7.0, all works fine.
Signed-off-by: Yonghong Song <yhs@fb.com>

docs: update BPF features list (tracepoints to debug eBPF were removed)

Tracepoints for debugging eBPF were removed from the kernel (some other
mechanisms were being used instead, and they were not used often enough
to get proper maintenance). Let's specify this on the related line in
BPF features doc.

introduce {attach|detach}_raw_tracepoint API

Update docs/kernel_versions

Update list of main features and supported map types.

Also update list of architectures supporting JIT, and main features
list, with important upcoming changes (x86_32 for JIT, bpfilter and
AF_XDP for main features).

Also add notes on top of the lists about how to obtain the items of each
list.

Remove speculative map types with no link or schedule.

- Update links in doc (make them point from net-next to linux, when
  relevant).
- Add helpers bpf_xdp_adjust_tail() and bpf_skb_get_xfrm_state() to
  documentation and headers.
- Synchronise helpers with latest net-next.

The motivation comes from pull request #1689.
It attached a kprobe bpf program to kernel function
ttwu_do_wakeup for more accurate tracing.
Unfortunately, it broke runqlat.py in my
4.17 environment since ttwu_do_wakeup function
is inlined in my kernel with gcc 7.3.1.

4.17 introduced raw_tracepoint and this patch
added the relevant API to bcc. With this,
we can use tracepoints
sched:{sched_wakeup, sched_wakeup_new, sched_switch}
to measure runq latency more reliably.
Signed-off-by: Yonghong Song <yhs@fb.com>

Misc improvements to C++ API and example

introduce C++ get_syscall_fnname API

Support Cgroup Array in BCC

This fixed issue #1695 for C++. The example
HelloWorld.cc and tests test_libbcc also got fixed.
Signed-off-by: Yonghong Song <yhs@fb.com>

document cflags argument to BPF()

Refactor profile.py stack id error handling

using get_syscall_fnname to get kprobe func name for tools

Refactor offwaketime stack id error handling

introduce new BPF APIs to get kernel syscall entry func name/prefix

Fixed tools which are attached to syscall entry functions
"sys_*". Instead, use get_syscall_fnname to get
proper names.
Signed-off-by: Yonghong Song <yhs@fb.com>

As described in issue #1695, on 4.17 for syscalls on x86,
both sys_<fnname> and SyS_<fnname> are gone, the replacements
are __ia32_sys_sync and __x64_sys_sync.
The commit in Linus tree:
https://github.com/torvalds/linux/commit/d5a00528b58cdb2c71206e18bd021e34c4eab878

This patch introduced two APIs for python BPF object.
The API get_syscall_prefix() returns the prefix "sys_"/"__x64_sys_".
The API get_syscall_fnname(name) returns kernel function name for the syscall,
e.g., on x64, get_syscall_fnname("clone") will return "sys_clone" if kernel
has it, otherwise, "__x64_sys_clone".
get_syscall_prefix() is mostly useful for the regex func specifier of
attach_kprobe().

This patch only fixed the code using python API on examples and tests directory.

TOTO: python on tools directory, C++ and lua
Signed-off-by: Yonghong Song <yhs@fb.com>