Libclang uses functions from libbcc, so it does depend on it.
When defining new symbols in bpf_common.cc, linker errors appear
when the same symbols are used in libclang. This is because of
incorrect linker dependency. This patch fixes the issue by making
sure the dependency is correctly tracked.

Signed-off-by: Joel Fernandes <joelaf@google.com>

This patch adds BPFd, a standalone executable designed to provide BCC the
ability to work across system and architecture boundaries.

This is done by loading the BPFd executable onto a remote target device to
have it act as a proxy for whenever a BCC tool wishes to perform an operation on
the system (e.g. load BPF programs, read /proc/kallsyms, attach kprobes, etc.).

This arrangement allows developers to have kernel sources and the LLVM stack
on a separate host machine (e.g. the development machine) instead of needing
to set all these up on the target device, thereby allowing for the drastic
reduction of space required on a target for BCC tools to run. The reduction of
the space requirement, in particular, becomes a much more critical factor
for devices that have more limited disk space (e.g. embedded devices).

In addition, the above set-up also allows developers to run clang on a
different architecture than the target's architecture, thus facilitating
cross-compilation development.

However, the natural disadvantage for cross-developers is that there is a
need to have a copy of the target's kernel sources on the host for the
above set-up to work.

For more information, please check out the README in the original
BPFd repository (https://github.com/joelagnel/bpfd) and this LWN article
explaining the purpose of and how BPFd works in more detail
(https://lwn.net/Articles/744522/)

Signed-off-by: Jazel Canseco <jcanseco@google.com>

The bpf shared library (i.e. libbpf.so) is included since the bpfd
executable dynamically links to it.

Signed-off-by: Jazel Canseco <jcanseco@google.com>

This modifies BCC to query BPFd whenever BCC wishes to perform an
operation on a remote target device (e.g. load BPF programs, read
/proc/kallsyms, attach kprobes, etc.)

If no remote target device has been configured, BCC defaults to
performing the operations on the local system just like before.

Signed-off-by: Jazel Canseco <jcanseco@google.com>

Signed-off-by: Jazel Canseco <jcanseco@google.com>