The recent linux distros already support PIE so it shouldn't be a
problem to remove "-no-pie". To avoid issue#782, we make "-no-pie"
optional and enable it by default. For the distro with PIE luajit,
just add the following build option:

   -DENABLE_NO_PIE=OFF

Then, bcc-lua will be built with PIE support.

Signed-off-by: Gary Lin <glin@suse.com>

Meet the following compiler error:
/mnt/trace-tools/eBPF/bcc/src/cc/frontends/clang/b_frontend_action.cc:
In member function bool
ebpf::BTypeVisitor::VisitVarDecl(clang::VarDecl*):]
/mnt/trace-tools/eBPF/bcc/src/cc/frontends/clang/b_frontend_action.cc:1449:18:
error: BPF_MAP_TYPE_RINGBUF was not declared in this scope; did you mean
BPF_MAP_TYPE_QUEUE?
1449 | map_type = BPF_MAP_TYPE_RINGBUF; | ^~~~~~~~~~~~~~~~~~~~ |
     BPF_MAP_TYPE_QUEUE
make[2]: ***  [src/cc/frontends/clang/CMakeFiles/clang_frontend.dir/build.make:95:
rc/cc/frontends/clang/CMakeFiles/clang_frontend.dir/b_frontend_action.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1065: src/cc/frontends/clang/CMakeFiles/clang_frontend.dir/all] Error 2
make: *** [Makefile:160: all] Error 2

This because, submodule libbpf can't sync when do cmake.
So enlarger the sync contion: only submodule is clean, we do sync
submodle when do cmake.

Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>

Some of the executables still link to the local static versions
even if the user requested CMAKE_USE_LIBBPF_PACKAGE. Fix this by
using bcc-shared-no-libbpf more widely if the variable is set.

Skip the git submodule and the extraction commands if the user
set CMAKE_USE_LIBBPF_PACKAGE

ENABLE_LLVM_SHARED allows to dynamically link against libLLVM, but
libclang is still unconditionally linked statically.
Search for libclang-cpp.so, and if it is found and ENABLE_LLVM_SHARED
is set dynamically link against it.
Also expand the libstdc++ static linking check to include this new
condition.

Building examples and tests take up a lot of time and disk space.

In many use-cases, though, `bcc` is built solely for the library portion, as a dependency of another project.

This patch allows one to opt out of building the examples and tests, saving up time and disk space in the process. Default behavior (build them) is kept.

In my machine this lowers build time from 1.5 hours to 18 minutes.

attempting a cmake build with `ENABLE_CLANG_JIT` disabled and not `PYTHON_ONLY` fails with the following output:

root@4ec15b1c6d03:~/src/bcc/tmp# cmake -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD:STRING=20 -DCMAKE_C_FLAGS="-fPIC" -DCMAKE_INSTALL_PREFIX:PATH=/root/opt -DENABLE_CPP_API=ON -DENABLE_LLVM_NATIVECODEGEN=ON -DENABLE_LLVM_SHARED=OFF -DENABLE_MAN=OFF -DENABLE_RTTI=OFF -DINSTALL_CPP_EXAMPLES=OFF -DENABLE_CLANG_JIT=OFF ../src
-- Latest recognized Git tag is v0.17.0
-- Git HEAD is ad5b82a5
-- Revision is 0.17.0-ad5b82a5
CMake Error at src/cc/CMakeLists.txt:31 (string):
  string sub-command REGEX, mode MATCH needs at least 5 arguments total to
  command.


CMake Error at src/cc/CMakeLists.txt:61 (if):
  if given arguments:

    "VERSION_EQUAL" "6" "OR" "VERSION_GREATER" "6"

  Unknown arguments specified


-- Configuring incomplete, errors occurred!
See also "/root/src/bcc/tmp/CMakeFiles/CMakeOutput.log".
```

The reason for the failure is that `LLVM` is required by [`src/cc/CMakeLists.txt`](https://github.com/iovisor/bcc/blob/297512a31ecc9ceebf79bda169350dace0f36757/src/cc/CMakeLists.txt#L61), which is included for non `PYTHON_ONLY` builds by [`src/CMakeLists.txt`](https://github.com/iovisor/bcc/blob/297512a31ecc9ceebf79bda169350dace0f36757/src/CMakeLists.txt#L16). Yet, `LLVM` is only looked up by [`/CMakeLists.txt`](https://github.com/iovisor/bcc/blob/297512a31ecc9ceebf79bda169350dace0f36757/CMakeLists.txt#L54) whenever `ENABLE_CLANG_JIT` is enabled.

The proposed fix looks up `LLVM` whenever `PYTHON_ONLY` is disabled, even if `ENABLE_CLANG_JIT` is disabled.

This is the output after the fix is applied:
```
root@4ec15b1c6d03:~/src/bcc/tmp# cmake -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD:STRING=20 -DCMAKE_C_FLAGS="-fPIC" -DCMAKE_INSTALL_PREFIX:PATH=/root/opt -DENABLE_CPP_API=ON -DENABLE_LLVM_NATIVECODEGEN=ON -DENABLE_LLVM_SHARED=OFF -DENABLE_MAN=OFF -DENABLE_RTTI=OFF -DINSTALL_CPP_EXAMPLES=OFF -DENABLE_CLANG_JIT=OFF ../src
-- The C compiler identification is GNU 10.2.1
...
-- Build files have been written to: /root/src/bcc/tmp
root@4ec15b1c6d03:~/src/bcc/tmp# make -j`nproc --all`
Scanning dependencies of target bpf-static
Scanning dependencies of target bpf-shared
[  2%] Building C object src/cc/CMakeFiles/bpf-static.dir/libbpf.c.o
...
[100%] Built target bps
root@4ec15b1c6d03:~/src/bcc/tmp#

It's sometimes convenient to use other kernel headers,
now it's possible possible with new KERNEL_INCLUDE_DIRS
build variable, like:

  $ cd <kernel-dir>
  $ make INSTALL_HDR_PATH=/tmp/headers headers_install
  $ cd <bcc-dir>
  $ cmake -DKERNEL_INCLUDE_DIRS=/tmp/headers/include/ ...

Signed-off-by: Jiri Olsa <jolsa@kernel.org>

some distros already packaging clang 10 (checked fedora and arch) no longer
ship all the individual libclang*.so component libraries.
Instead, clang from 9.0 onwards provides a new lib, libclang-cpp.so, which
includes everything we need.

Tell cmake to use it if the individual libraries are no longer found.
(Build-wise, if both are present it is more efficient to use the individual
components so keep these first)

* make -DCMAKE_INSTALL_PREFIX=/usr as the default
* remove -DCMAKE_INSTALL_PEREFIX=/usr from INSTALL.md  as it gets the default

Which links libbpf.so dynamicaly, instead of its current
static inclusion in libbcc.so.

The compilation needs to define CMAKE_USE_LIBBPF_PACKAGE
variable to enable search for libbpf package. If the package
is found it is used to build all the bcc libs.

The libbcc.so and libbcc_bpf.so (and their static versions)
remain the same.

The new library libbcc-no-libbpf.so is built from all libcc.so
sources including libbpf_bcc.so's sources: libbpf.c perf_reader.c
and dynamically linked to libbpf.so library.

With libbcc-no-libbpf.so symbols are versioned, so there's
no chance of being mixed:

Symbols exported from libbpf.so:

  $ objdump -T /usr/lib64/libbpf.so | grep bpf_map_lookup_elem
  0000000000006df0 g    DF .text  000000000000006e  LIBBPF_0.0.1 bpf_map_lookup_elem
  0000000000006e60 g    DF .text  0000000000000076  LIBBPF_0.0.2 bpf_map_lookup_elem_flags

Symbol needed by libbcc-no-libbpf.so:

  $ objdump -T /opt/bcc/lib64/libbcc-no-libbpf.so | grep bpf_map_lookup_elem
  0000000000000000      DF *UND*  0000000000000000  LIBBPF_0.0.1 bpf_map_lookup_elem

Symbols exported by current libbcc.so:

  $ objdump -T /opt/bcc/lib64/libbcc.so | grep bpf_map_lookup_elem
  00000000023ad843 g    DF .text  0000000000000082  Base        bpf_map_lookup_elem_flags
  00000000023ad7d3 g    DF .text  0000000000000070  Base        bpf_map_lookup_elem

Besides that it's better to share common source of libbpf code,
it also prevents issues when having application that links to
libbpf and libbcc, where you could end up conflicting functions
and segfaults if those 2 libbpf libs are not on the same version.

All installed libraries now:

  total 259096
  lrwxrwxrwx. 1 root root        15 Nov  8 15:24 libbcc_bpf.so -> libbcc_bpf.so.0
  lrwxrwxrwx. 1 root root        20 Nov  8 15:24 libbcc_bpf.so.0 -> libbcc_bpf.so.0.11.0
  -rwxr-xr-x. 1 root root    453416 Nov 11 17:03 libbcc_bpf.so.0.11.0
  lrwxrwxrwx. 1 root root        21 Nov  8 15:24 libbcc-no-libbpf.so -> libbcc-no-libbpf.so.0
  lrwxrwxrwx. 1 root root        26 Nov  8 15:24 libbcc-no-libbpf.so.0 -> libbcc-no-libbpf.so.0.11.0
  -rwxr-xr-x. 1 root root 132276312 Nov 11 17:04 libbcc-no-libbpf.so.0.11.0
  lrwxrwxrwx. 1 root root        11 Nov  8 15:24 libbcc.so -> libbcc.so.0
  lrwxrwxrwx. 1 root root        16 Nov  8 15:24 libbcc.so.0 -> libbcc.so.0.11.0
  -rwxr-xr-x. 1 root root 132579280 Nov 11 17:04 libbcc.so.0.11.0
  drwxr-xr-x. 2 root root        23 Nov 11 21:49 pkgconfig

Signed-off-by: Jiri Olsa <jolsa@kernel.org>

The latest llvm trunk (llvm 10) built require c++14.
Built with gcc and llvm 10 headers, the following
error will show up:
  ...
  /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/RWMutex.h:
      At global scope:
  /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/RWMutex.h:101:8:
      error: ‘shared_t$
  med_mutex’ in namespace ‘std’ does not name a type
     std::shared_timed_mutex impl;
  ...
  /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/TrailingObjects.h:252:19:
      error: ‘is_final’ is not a member of ‘std’
       static_assert(std::is_final<BaseTy>(), "BaseTy must be final.");
  ...

std::shared_timed_mutex and std::is_final etc. are all c++14 features.
Most compilers should already support c++14. Let us require it in
Makefile now.

Signed-off-by: Yonghong Song <yhs@fb.com>

Avoid building man pages when it's not necessary
(i.e when building for an embedded system).

Signed-off-by: Romain Naour <romain.naour@gmail.com>

If the target directory src/cc/libbpf/ does not exist,
the top level CMakeLists.txt is changed to fetch
submodules with the following command
  git submodule update --init --recursive

The dev/rpm build scripts are also changed
to do git submodule update.

Signed-off-by: Yonghong Song <yhs@fb.com>

* Make dependency on LLVM native target optional

Adds an option ENABLE_LLVM_NATIVECODEGEN with default value ON.
If set to off the "nativecodegen" llvm will not be enabled, thus
reducing dependencies on needed libraries (reduced text size when
building with statically linked libraries).

Code that uses native target will not be compiled reducing text size.
Currently this affects the rw_engine which needs the native target.

BPF api "rw_engine_enabled" will have default value "true" if
ENABLE_LLVM_NATIVECODEGEN="ON" and "false" if
ENABLE_LLVM_NATIVECODEGEN="OFF"

Not needed for BCC to work. It somehow brought in the interpreter and
executionengine which is needed. Those features are added instead.

* Remove garbage in code making it compile again

* Remove interpreter and executionengine LLVM dependencies

These doesn't seem to be needed on a Ubuntu 18.04 system (although
executionengine is heavily used).

Interpreter was added due to runtime dependency on ARM64. It brings in
a dependency on ffi library.

(.text._ZL10ffiTypeForPN4llvm4TypeE+0x3a): undefined reference to `ffi_type_float'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x43): undefined reference to `ffi_type_void'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x53): undefined reference to `ffi_type_pointer'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x63): undefined reference to `ffi_type_double'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x78): undefined reference to `ffi_type_sint8'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x83): undefined reference to `ffi_type_sint16'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x93): undefined reference to `ffi_type_sint64'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0xb3): undefined reference to `ffi_type_sint32'
/usr/lib/llvm-6.0/lib/libLLVMInterpreter.a

Enables linking bcc-static in binaries compiled with rtti

In llvm/clang 8 trunk, the following commits
  https://reviews.llvm.org/rL339384
  https://reviews.llvm.org/rL339385
  https://reviews.llvm.org/rL339386


renames getLocStart to getBeginLoc, and getLocEnd to getEndLoc.
This caused bcc compilation error with llvm/clang 8.
To avoid proliferation of #define's based on LLVM version numbers
and similar logic for many different types,
this patch fixed the issues by define macros in common
frontend_action_common.h where macro definition is multi-versioned
based on llvm version. The macro itself is used in
{b,tp}_frontend_action.cc.

clang 8 also introduced a new library dependency
  libclangAnalysis.a depends on libclangASTMatchers.a
This patch fixed this issue as well.

Signed-off-by: Yonghong Song <yhs@fb.com>

* tools: use printb for more python3 compat

Switch to printb in killsnoop and wakeuptime

* tests: use subproceess sleep to trigger test

In some python implementations, time.sleep uses select instead of
nanosleep and hence won't trigger the bpf kprobe.

* tools: remove explicit python3 shebang

Use an ambiguous python invocation in the shebang line. Instead, rely on
packaging stage to mangle the line to specify a python version.

* cmake: add ENABLE_LLVM_SHARED option

This adds an option to specify that only the dynamic libraries should be
used to link bcc. This is most likely to be used in systems that don't
build/provide the llvm-static and clang-static package options
(fedora-based).

* rpm: enable llvm_shared and python3 build options

Enable rpm packaging with two new features:
 - shared-only packaging (no static linking)
 - python3
To enable these build features (off by default), run:
 RPM_WITH_OPTS="--with llvm_shared --with python3" ./scripts/build-rpm.sh

* rpm: protect python3-bcc package declaration

Don't define python3-bcc if --with python3 isn't explicitly specified.

* specs: only build python3 if requested

* man: compress man pages

* specs: enable python3 by default in fc28+/rh8+

- Enable llvm_shared and python3 --with options by default in new fedora
- Fix string quoting
- Update spec changelog

A simple program to list all bpf programs of a system.

[root@arch-fb-vm1 bcc]# ./build/introspection/bps -h
BPF Program Snapshot (bps):
List of all BPF programs loaded into the system.

Usage: bps [bpf-prog-id]
    [bpf-prog-id] If specified, it shows the details info of the bpf-prog

* List all bpf programs *
[root@arch-fb-vm1 bcc]# ./build/introspection/bps
      BID TYPE                 UID  #MAPS LoadTime     NAME
       82 kprobe                 0      1 Oct19/23:52  map_perf_test
       83 kprobe                 0      1 Oct19/23:52  map_perf_test
       84 kprobe                 0      1 Oct19/23:52  map_perf_test
       85 kprobe                 0      1 Oct19/23:52  map_perf_test
       86 kprobe                 0      4 Oct19/23:52  map_perf_test
       87 kprobe                 0      1 Oct19/23:52  map_perf_test
       88 kprobe                 0      1 Oct19/23:52  map_perf_test
       89 kprobe                 0      1 Oct19/23:52  map_perf_test

* List a particular bpf program *
[root@arch-fb-vm1 bcc]# ./build/introspection/bps 86
      BID TYPE                 UID  #MAPS LoadTime     NAME
       86 kprobe                 0      4 Oct19/23:52  map_perf_test

     MID TYPE            FLAGS         KeySz  ValueSz  MaxEnts NAME
     120 lru hash        0x0               4        8    10000 lru_hash_map
     129 lru hash        0x0               4        8       43 lru_hash_lookup
     123 array of maps   0x0               4        4     1024 array_of_lru_ha
     121 lru hash        0x2               4        8    10000 nocommon_lru_ha

* JIT disabled *
[root@arch-fb-vm1 bpf]# sysctl -w net.core.bpf_jit_enable=0
[root@arch-fb-vm1 bpf]# ./test_progs
[root@arch-fb-vm1 bcc]# ./build/introspection/bps
      BID TYPE                 UID  #MAPS LoadTime     NAME
      94- socket filter          0      1 Oct19/23:55  test_obj_id
      95- socket filter          0      1 Oct19/23:55  test_obj_id

* Run without CAP_SYS_ADMIN *
[kafai@arch-fb-vm1 ~]$ ./bps 1
Require CAP_SYS_ADMIN capability.  Please retry as root

* Older kernel *
[root@arch-fb-vm2 build]# uname -r
4.12.14
[root@arch-fb-vm2 build]# ./introspection/bps 1
Kernel does not support BPF introspection

Signed-off-by: Martin KaFai Lau <kafai@fb.com>

The patch adds a new debug option "DEBUG_SOURCE = 8" to
dump insns embedded with source. In C++ API, users
can change BPF constructor "flag" value to enable debug output.
In Python API, users can change "debug" value to enable
debug output. For example, for python test program test_usdt.py,
the debug output looks like below:

......
Disassembly of section .bpf.fn.do_trace1:
do_trace1:
; int do_trace1(struct pt_regs *ctx) { // Line 110
   0:   bf 16 00 00 00 00 00 00         r6 = r1
   1:   b7 01 00 00 00 00 00 00         r1 = 0
; struct probe_result_t1 result = {}; // Line 111
   2:   7b 1a f0 ff 00 00 00 00         *(u64 *)(r10 - 16) = r1
; switch(ctx->ip) { // Line   5
   3:   79 61 80 00 00 00 00 00         r1 = *(u64 *)(r6 + 128)
   4:   15 01 04 00 d7 06 40 00         if r1 == 4196055 goto 4
   5:   55 01 06 00 ce 06 40 00         if r1 != 4196046 goto 6
; case 0x4006ceULL: *((int8_t *)dest) = ctx->ax; __asm__ __volatile__("": : :"memory"); return 0; // Line   6
   6:   79 61 50 00 00 00 00 00         r1 = *(u64 *)(r6 + 80)
......

For asm insns, byte code is also dumped out (similar to objdump).
For source codes, only lines in the module file are printed (as expected).
The line number is added at the end of source code, which is
especially helpful for inlined functions.

This functionality is only in llvm 6.x (the trunk version), which
provides an public interface to create a dwarf context based on
a set of in-memory debug sections. llvm 5.x also provides
such a public interface in a different way, and this patch
does not support it in bcc yet. llvm 4.x and lower do not
have such a public interface and hence will not be supported
in bcc.

In this patch, the debug output only goes to stderr.
A subsequent patch will dump the per-function output into
<BCC_PROG_TAG_DIR>/bpf_prog_<tag>/ if it is available.

Signed-off-by: Yonghong Song <yhs@fb.com>

during debug of production systems it's difficult to trace back
the kernel reported 'bpf_prog_4985bb0bd6c69631' symbols to the source code
of the program, hence teach bcc to store the main function source
in the /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/ directory.

This program tag is stable. Every time the script is called the tag
will be the same unless source code of the program changes.
During active development of bcc scripts the /var/tmp/bcc/ dir can
get a bunch of stale tags. The users have to trim that dir manually.

Python scripts can be modified to use this feature too, but probably
need to be gated by the flag. For c++ api I think it makes sense
to store the source code always, since the cost is minimal and
c++ api is used by long running services.

Example:
$ ./examples/cpp/LLCStat
$ ls -l /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/
total 16
-rw-r--r--. 1 root root 226 Sep  1 17:30 on_cache_miss.c
-rw-r--r--. 1 root root 487 Sep  1 17:30 on_cache_miss.rewritten.c
-rw-r--r--. 1 root root 224 Sep  1 17:30 on_cache_ref.c
-rw-r--r--. 1 root root 484 Sep  1 17:30 on_cache_ref.rewritten.c

Note that there are two .c files there, since two different
bpf programs have exactly the same bytecode hence same prog_tag.

$ cat /var/tmp/bcc/bpf_prog_4985bb0bd6c69631/on_cache_miss.c
int on_cache_miss(struct bpf_perf_event_data *ctx) {
    struct event_t key = {};
    get_key(&key);

    u64 zero = 0, *val;
    val = miss_count.lookup_or_init(&key, &zero);
...

Signed-off-by: Alexei Starovoitov <ast@fb.com>

Allow building of JUST the libbpf library and related headers. No clang,
llvm, python, lua, etc. Not even tests :(

Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Move the C++ api files under a new subdirectory.
Use CMAKE_DEPENDENT_OPTION to enforce sdt->cpp_api relationship.

Since linking .a into a .so can cause global symbols to be dropped, add
a helper file to force exported symbols to be retained (link_all.cc).
This problem doesn't exist for building the static cpp examples.

Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Certain versions of recent gcc (e.g., gcc 6.3.0 on ubuntu17.04)
has pie enabled by default at linker (collect2) stage.
The compilation flag "-no-pie" is available to negate
this linker option.

Add -no-pie to compilation flag only if it is available.
Earlier gcc compiler may not have this option but it does
not have linker pie on-by-default either.

Tested with ubuntu 17.04 and my local gcc 4.8.5 (not accepting -no-pie).

Signed-off-by: Yonghong Song <yhs@fb.com>

The build type was set to Release in the top level cmake file.
This was a rather confusing behaviour, as one would expect to
be able to easily debug the code after using `cmake -DCMAKE_BUILD_TYPE=Debug`.

used the CheckCXXCompilerFlag module of Cmake to check the compiler whether or not supporting c++11. (#1116)

When using Clang 3.9(compiled by GCC 6.x), bcc will used -isystem,
because the GCC_VERSION(get the version of the Clang) is less 6.0.
And then the compiler will compile failed.

As some module build directories split headers between `source/` and
`build/` and this varies between distributions, determine the location
at runtime.

GCC 6 behaves slightly differently when using -isystem, and our use of
that parameter is causing a build failure. Avoid using -isystem on
gcc6+ for now, until that compiler becomes a bit more mainstream and
we can debug further.

Failure had been introuced in d19e0cb0.

Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

If LLVM_INCLUDE_DIRS includes multiple directories, separated by
semicolon, the string would be incorrectly propagated all the way down
to the shell, that would interpret such semicolon as a command
separator. E.g. we would have:

 c++ ... -isystem /w/llvm/include;/w/llvm/bld/include ...

Instead, we need to parse the string as a CMake list (that are defined
as strings composed by semicolon-separated tokens) and build a string
in the form:

 c++ ... -isystem /w/llvm/include -isystem /w/llvm/bld/include ...

This bug was introduced in d19e0cb0.
This commit fixes #707.

Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

* Flag ${LLVM_INCLUDE_DIRS} as a system include directory

g++ supports a -isystem switch, that can be used to mark a given
directory as a system include directory. Warnings generated by system
include directories are ignored by default.

This commit hides a long list of warnings, like the following one,
generated by llvm header files included from ${LLVM_INCLUDE_DIRS}:

 /usr/lib/llvm-3.7/include/clang/AST/APValue.h:373:44: warning:
   dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

* Fix 'defined but not used' warning

Remove unused function from the USDT probes test.

The warning was:

 tests/cc/test_usdt_probes.cc:59:15: warning:
   ‘size_t countsubs(const string&, const string&)’ defined but not used [-Wunused-function]

Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

Add a new a `FindLibElf.cmake` package, and use it to link the main
`libbcc` library against the system's LibELF. This library will be used
to re-implement functionality that was previously dependent on
`binutils`.

Instead of importing the `Find*.cmake` modules directly, place them in
the root `cmake/` folder and define it as a CMake Module path. This lets
us use the `find_package` builtin to require any given packages.

Add support for systems using a non-default ("/lib/modules") kernel lib
directory.

Some linux distributions structure the /lib/modules directories
differently, causing complexities. Add cmake overrides to be able to
compile different behavior.

If your distro sets up `/lib/modules/$(uname -r)/{source,build}` with
header files split between the two (debian does this), then add
-DBCC_KERNEL_HAS_SOURCE_DIR=1 to the cmake command line.

If your distro just has something other than build/, but things are
still in one subdirectory, then add -DBCC_KERNEL_MODULES_SUFFIX=foo to
the cmake command line.

Also, fix one implicit declaration warning introduced by the new
bpf_get_stackid() helper.

Fixes: #397
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

Signed-off-by: Gary Lin <glin@suse.com>

Ticket: #291
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

This should be supported in older versions of cmake, but haven't
explicitly tested those.

Fixes: #243
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>