Remove debug flag override in bcc_exception.h

Clean up bcc_exception.h

biotop.py: fix compiler error on newer kernels

Determine kernel dirs at runtime (fix #743)

Add LLVMCoroutines lib for llvm>=4.0 builds

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>

Improve the structure of exception related header files

tcplife.py: Catch passive closed by server, #788

C++ helper class for BCC

* Eliminate rpmlint errors and allow bcc srpm to build on Fedora koji build system

The nightly bcc srpm does not build as-is on Fedora 24. To get the
build to work the following changes were made in the bcc.spec file:

-Specify where to find luajit headers and libraries
-Correctly limit the build to the x86_64 architecture
-Add needed build requires so the srpm can build on Fedora koji
-Run ldconfig so shared library information is updated
-Follow spec conventions by putting %changelog at the end of the spec file

* Further refine the bcc.spec file

Make the following improvements to the gcc.spec file:

-Use local_clang_static variable to allow building with locally installed clang
-Adjust build requires to include nucurses-devel and make
-Put the subpackage descriptions and file list in a more logical order
-Correct the binary rpm dependencies for the subpackages

Fixup test errors in clang, c api

Some errors seem to have cropped up due to updating kernels and clang
library versions.
1. test_c_api fails on kernels (seen on fedora 4.9) where startup_64
doesn't start at a particular address. Simplify the test to hopefully
work in more systems.
2. The lua and python test_clang did a dereference on a particular bio
field, which has been removed. Pick a different field that is more
uniquitous.
3. test_xlate1 was generating code where the verified pointer spilled.
Rewrite the example to store the result on the stack.
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

trace: Avoid passing -1 as the pid to USDT

When the `-p` switch is used with `trace`, it would set
the tgid to the value passed to `-p` and set the pid to
-1. The result would be incorrect logic that passed the -1
pid value to the `USDT` context constructor, which fails
for probes that require the pid to enable (because they
have a semaphore that needs a poke). This commit fixes it.

cc, python: Clean up BPF module and tables

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.

Make bcc_symcache_new(tid) work with symbols from /tmp/perf-pid.map

Fix warnings covered by -Wdelete-non-virtual-dtor

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>