GitLab

To resolve library names, bcc_procutils_which_so leverages mapped
libraries of the targeted process, if one is given. Uses the kernel's
/proc/$pid/maps

Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>

When compiling ebpf programs on Alpine Linux the compiler throws the following
error:

LLVM ERROR: Cannot select: 0x56049b79dcb0: ch,glue = BPFISD::CALL 0x56049a93ad60, TargetExternalSymbol:i64'__stack_chk_fail'
  0x56049b391500: i64 = TargetExternalSymbol'__stack_chk_fail'
    In function: waker

Disabling the stack protector explicitly with '-fno-stack-protector'
fixes this error.

clang version 3.8.1 (tags/RELEASE_381/final)
Target: x86_64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/bin
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>

Avoid conflicting [no]inline attributes in function annotation. This was
probably always there but now 4.0 is treating this as an error.
Also, explicitly inline several functions in helpers.h.

Turn off unwind tables in the flags passed to clang. This was generating
calls to the elf relocator, which doesn't work for the BPF target. It is
unclear which change in LLVM 4.0 altered this behavior.

On python3, handle byte strings in the usual way for supporting
backwards compatibility.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>

Only the virtual_bpf.h should point to the installed kernel headers.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>

As is occassionally necessary, we need to update the compat header
files for new kernels. This picks up the bpf.h from 4.10rc1.

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

ABI for aarch64: register x0-x7 are used for parameter and result. In
bcc, there are 6 parameter registers are defined. So use x0-x5 as
parameter. frame pointer, link register, stack pointer and pc are added
in PT_REGS_xx according to arm64 architecture.

syscall number of bpf for aarch64 are defined in Kernel
header uapi/asm-generic/unistd.h.
Signed-off-by: Zhiyi Sun <zhiyisun@gmail.com>

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

Building bcc against a tip of tree llvm introduces a new link failure,
which is fixed by linking against libLLVMCoroutines (which only exists
in 4.0).
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

When the `BPFModule` object is destroyed, shared tables
were closed, but non-shared tables were not. Add `close`
call to close non-shared tables in `~BPFModule`.

Make sure the `BPF.cleanup` function in the Python module
calls `bpf_module_destroy` to clean up the module. Otherwise,
we have hanging table fds that aren't destroyed.

Fixes #806. This would have been an issue for any tool
that repeatedly runs a BPF program with new maps. It's just
that most tools we have haven't exhibited this behavior.

The warnings were:

 src/cc/bcc_syms.cc: In function ‘void bcc_free_symcache(void*, int)’:
 src/cc/bcc_syms.cc:217:40: warning: deleting object of polymorphic class type ‘KSyms’
                            which has non-virtual destructor might cause undefined behaviour
                            [-Wdelete-non-virtual-dtor]
     delete static_cast<KSyms*>(symcache);
                                        ^
 src/cc/bcc_syms.cc:219:43: warning: deleting object of polymorphic class type ‘ProcSyms’
                            which has non-virtual destructor might cause undefined behaviour
                            [-Wdelete-non-virtual-dtor]
     delete static_cast<ProcSyms*>(symcache);
                                           ^

Fix the warnings by defining a virtual destructor for the base class SymbolCache.
Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

Ref: iovisor/bcc#778