u* tools: automatically detect the language (#1067)

* cc: bcc function to detect the language of a process

bcc_procutils_language looks into /proc/$pid/cmdline, /proc/$pid/exe,
and /proc/$pid/maps to determine the language.
Python wrapper takes a list of candidate languages; if the detected
language is not part of the list, None is returned.

* u* tools: automatically detect the language

Uses the detect_language bcc helper. -l switch can override the
detected language. In uthreads and ucalls, the language can be
overwritten to 'none' to trace pthreads and syscalls respectively.

All tools use the -l switch to set the language, for consistency.

Merge pull request #1076 from palmtenor/helpermacro

Improve helper Macros

bcc container improvements (#1051)

* Bcc should look at mountns during symbol resolution.

Allow bcc to resolve symbols in processes that have mappings in a
different mount namespace.  This allows us to obtain stack traces from
the host when our target resides in a container.  With this change it's
possible to get stacks from targets that used to show up as unknown.

* When searching for perf-map files look in container, and then host.

Allow perf-map files to exist either in the container under the pid
that's specific to the container's pid namespace, or in the host
container using the pid that's specific to the initial pid namespace.
This lets us store the perf-map either in the continer or on the host,
depending upon which is easier for the person performing the debugging.

* Allow bcc to place uprobes and USDT probes in containers.

The uprobe/usdt mechanism uses the target's inode in order to determine
where to place the probe.  The inode lookup occurs at the time the file
path is written to uprobe_events.  If bpf_attach_uprobe() has been
passed a pid, and that pid is in a different mount namespace from the
caller, attempt to switch to the victim's mount namespace so that we can
select the correct inode for the probe.

* Add unit tests for the container improvements code.

Update documentation for new helper Macros

Use new helper Macro across files

Improve BPF helper Macros

cc: define load_func and unload_func public (#1065)

With the current API it is not possible to load any kind of ebpf
program, for example BPF_PROG_TYPE_SCHED_CLS, this commit solves that by
defining load_func and unload_func as part of the public API.

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

Merge pull request #1068 from goldshtn/syscount-python3

syscount: Use zip_longest for Python 3 compatibility

Merge pull request #1069 from pchaigno/links

LINKS.md

Merge pull request #1066 from pchaigno/remove-import-netaddr

solisten: replace netaddr with socket library

Create LINKS.md

syscount: Use zip_longest for Python 3 compatibility

Python 3 compatibility fixes around string handling (#986)

This fixes the bcc module and all the affected tools for issues related to string handling in Python 3. Specifically, when passing Python strings to C libraries they are encoded as ASCII, and when constructing Python strings from C strings, they are decoded first.

Merge pull request #1061 from lcp/kernel-docs

docs: add the supplementary commits for LRU hashes

solisten: replace netaddr with socket library

docs: add the supplementary commits for LRU hashes

This commit addes two kernel commits for the LRU hashes to provide the
more information about LRU hashes. The original commits (29ba732acbee
and 8f8449384ec3) mark the inclusion of LRU hashes, but the commit
messages do not mention the details. The commits 3a08c2fd7634 and
961578b63474 actually implement the LRU list and provide the detailed
information about why LRU hash is created and how it works, and this can
help people to understand LRU hashes more quickly.

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

Merge pull request #1060 from qmonnet/kernelfeatures

docs: update features list (new maps: array/hash of maps)

docs: update features list (new maps: array/hash of maps)

Merge pull request #1046 from pchaigno/check-fmt-printk

Verify format specifiers in bpf_trace_printk in rewriter

Merge pull request #1059 from pchaigno/fix-readme-markdown

Fix the Markdown list in the README

Merge pull request #1058 from ColinIanKing/master

snapcraft: add in some new tools missing from the snapcraft apps list

Fix the Markdown list in the README

snapcraft: add in some new tools missing from the snapcraft apps list

Add in bpflist and mysqld_qslower to apps list and re-order
dbstat in the list.

Signed-off-by: Colin Ian King <colin.king@canonical.com>

Verify format specifiers in bpf_trace_printk in rewriter

Verifies format specifiers while rewriting calls to bpf_trace_printk
and prints a warning the printk will be rejected by the kernel at
runtime.

For tests, redirects stderr at the file descriptor level in order to
catch warnings from the C library.

Merge pull request #1053 from palmtenor/bufferepoll

Use epoll in BPFPerfBuffer

Merge pull request #1056 from goldshtn/bpflist-enh

bpflist: Add to tests and use Python directory listing

Merge pull request #1055 from goldshtn/syms-encode

python: Allow module=None when resolving kernel symbols

tcplife for Lua (#1052)

Use epoll in BPFPerfBuffer

Close all opened CPU perf buffer (not only currently online ones)

Merge pull request #1050 from palmtenor/exampleinstall

Add build option for installing C++ examples

Add build option for installing C++ examples

Merge pull request #1032 from goldshtn/tools-tests

Smoke tests for the tools

tests: Add smoke tests for most tools

This commit adds basic smoke tests for most tools in tools/ by
running the tool with either a short duration, or interrupting it
with a SIGINT after a short duration. The tests check the return
value from the tool to detect any Python exceptions or other
errors, but they do not read the standard error or standard output
and parse the tool's result.

Some tools are not covered by these smoke tests for reasons
documented in the test itself:

* btrfsdist and btrfsslower need btrfs
* cachetop doesn't like to run without a terminal
* dbslower, dbstat, and mysqld_qslower need a database engine
* deadlock_detector allocates a huge amount of memory
* softirqs doesn't work on new kernels and needs fixing (#1031)
* ugc needs a USDT-enabled runtime with GC probes
* zfsdist and zfsslower need zfs

This is a good place to start, but clearly for some tools,
especially those with a complex interface like trace and argdist,
we need more than just basic smoke tests.

trace: Exit with nonzero return code on error

Merge pull request #1044 from goldshtn/ausyscall

syscount: Use ausyscalls if available to get syscall list

Merge pull request #1043 from goldshtn/bpflist

bpflist: Display processes with running BPF programs and maps

Merge pull request #1039 from iovisor/tag_v0.3.0

Prepare debian changelog for v0.3.0 tag

Prepare debian changelog for v0.3.0 tag

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

bpflist: Display processes with running BPF programs and maps

This tool displays processes with running BPF programs and maps,
and also optionally kprobes and uprobes. This is a poor-man's version
that snoops BPF file descriptors, as proposed by @brendangregg.

Example:

```
PID    COMM             TYPE     COUNT
4058   fileslower       prog     4
4058   fileslower       map      2
4106   bashreadline     map      1
4106   bashreadline     prog     1
```

Resolves #1036.

syscount: Use ausyscalls if available to get syscall list

If ausyscall is installed, it can provide a clean, up-to-date list of
syscall numbers for the current architecture. This is much more useful
than the default hardcoded list for x86-64, which is currently used by
syscount.

Try to run `ausyscall --dump` and parse the output before resorting to
the static list. Tested on FC/Linux 4.9 and produces 327 syscalls.

Resolves #1001.

Merge pull request #1034 from brendangregg/master

funclatency: remove unnecessary include

Merge pull request #1030 from zvonkok/zvonkok-s390x

Added s390x support. Needs 4.10 Kernel

funclatency: remove unnecessary include

Added s390x support. Needs 4.10 Kernel

Merge pull request #1005 from pchaigno/rewrite-only-deref

Restrict rewrite of unary operators to dereference operator

Restrict rewrite of unary operators to dereference operator

Since the whole expression, unary operator included, is replaced by a
call to bpf_probe_read, the dereference operator is currently the
only unary operator properly rewritten. When rewriting an increment
expression (++val) for instance, the increment operator is lost in
translation.

Trying to rewrite all unary operators sometimes confuses bcc and
results in improper code, for instance when trying to rewrite a
logical negation.

Merge pull request #1027 from fajs/debuild_no_parallel_tests

debuild: Do not parallelize tests

debuild: Do not parallelize tests

The tests in the test suite are not parallelizable and will fail if run
in parallel. Make the test step non-parallel to fix this issue.

Merge pull request #1006 from pchaigno/fix-bpf_dins_pkt-rewrite

Fix bpf_dins_pkt rewrite in BinaryOperator

Merge pull request #1024 from r4f4/explicit-static

cmake: Explicitly mark static libraries as such

Merge pull request #1023 from dneiter/filetop_sort

filetop: support specifying sort column via cmdline argument

cmake: Explicitly mark static libraries as such

Some distros (e.g Fedora) override the default behaviour of building
static libraries to building dynamic ones instead. By explicitly
building the correct libraries as static, we make sure BCC properly
compiles everywhere.

Fix bpf_dins_pkt rewrite in BinaryOperator

Binary operator expressions where the left hand-side expression is a
reference to the packet are replaced by a call to the bpf_dins_pkt
helper. When replacing text, the Clang Rewriter tries to maintain a
list of offsets between the original and the new position of tokens.

Replacing the whole binary operator expression with the call to
bpf_dins_pkt confuses the Rewriter and it is unable to track the new
position of the right hand-side expression. Rewriting the binary
operator expression in two times without rewriting the right
hand-side expression itself solves the issue.

Travis CI build to check compliance with PEP8 (#987)

* Travis CI build to check compliance with PEP8

* argdist: linter cleanup

* dbslower: linter cleanup

* dbstat: linter cleanup

* memleak: linter cleanup

* syscount: linter cleanup

* tplist: linter cleanup

* trace: linter cleanup

* ucalls: linter cleanup

* uflow: linter cleanup

* ugc: linter cleanup

* uobjnew: linter cleanup

* ustat: linter cleanup

offwaketime.py for older kernels (#977)

Merge pull request #1021 from markdrayton/sym-mod-fix

python: handle null module in BPF.sym

Merge pull request #1022 from goldshtn/syms-multiple-regions

Symbol resolution with multiple executable regions per module

Merge pull request #1018 from GabrielGanne/python-xdp-return-values

add XDP return values to python interface

cc: Symbol resolution with multiple executable regions per module

The symbol resolution code used to assume for most purposes that
there is a single executable region per module. When there were
several, there was no crash, but symbols were not resolved correctly.
The reason is that the symbol offsets are relative to the first
executable region's start address, but bcc would resolve them
relative to the region in which they appeared. For example, given
the following regions and spans for a module libfoo.so loaded into
some process:

  1000-2000 r-xp libfoo.so
  2000-3000 rw-p libfoo.so
  3000-4000 r-xp libfoo.so
  4000-5000 r--- libfoo.so

Now, suppose there is a symbol bar() loaded at address 3500. In
the binary on disk, bar() is at offset 2500 from the beginning of
the module (but not the beginning of the 3000-4000 region!). When
we look at the candidate regions, we find 3000-4000, and discover
that 3500 lies within it. Then we subtract 3500-3000 to find the
offset from the beginning of the region, get 500, and now look
for a symbol that contains the relative address 500. As a result,
we might find some random symbol in the region 1000-2000, and
report that address 3500 corresponds to that random symbol rather
than to bar().

This commit fixes the situation by keeping only a single `Module`
instance for each module, even if that module spans multiple
executable regions. We remember all executable region start and
end ranges so we can determine whether an address (like 3500 in
the above example) lies within the module. But for the purpose of
finding the actual symbol, we need only the offset from the start
of the _first_ executable region, and then need to look up a symbol
based on that.

This was discovered and fixed while tracing .NET Core processes on
Linux, where libcoreclr.so (the main CLR binary) has several
executable regions. Resolving symbols from any but the first region
would produce totally bogus results.

cc: Fix assertion for debug builds

range Python 2 -> 3 compatibility (#983)

usdt: fix argument passing on python3 (#984)

This fixes the following error:

$: ./tplist -v -v -l /usr/lib64/dri/i965_dri.so
argument 1: <class 'TypeError'>: wrong type

Update tutorial_bcc_python_developer.md (#1017)

small typo

Merge pull request #1020 from goldshtn/duplicate_modules

cc: Don't parse the same module multiple times for USDT probes

cc: Don't parse the same module multiple times for USDT probes

If a module has more than one executable region, it is reported
multiple times by `bcc_procutils_each_module`. This is fine for
symbol resolution, but we don't need the duplicates for parsing
the ELF header looking for USDT probes: the first appearance of
that module is enough. This also prevents issues with the same
probe appearing multiple times with the same location, which
results in an invalid program when reading USDT arguments.

Fix by storing each visited module in the USDT::Context class,
and ignoring modules that were already visited.

add XDP return values to python interface

Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
Signed-off-by: Romain Ly <romain.ly@enea.com>

python: handle null module in BPF.sym

Check to see if `module` is None before attempting to call `os.path.basename`
on it. Before:

```
>>> BPF.sym(0x400001, 12345, show_module=True)
Traceback (most recent call last):
..
AttributeError: 'NoneType' object has no attribute 'rfind'
```

After:

```
>>> BPF.sym(0x400001, 12345, show_module=True)
'[unknown]'
```

filetop: support specifying sort column via cmdline argument

Merge pull request #1015 from goldshtn/perfmap-retry

cc: Retry symbol resolution using perfmap

Merge pull request #1002 from goldshtn/nested-symbols

cc: Handle nested functions correctly when resolving symbols

Merge pull request #1012 from goldshtn/buildid-fix

cc: Fix SEGV when there is no build-id section

Merge pull request #1014 from iovisor/test-debuginfo-fix

Fix long running test_debuginfo and python3 fix

Fix long running test_debuginfo and python3 fix

Make sure subclass calls super().tearDown to clean up dummy process.
Also, fixup a python3 str.encode().

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

cc: Retry symbol resolution using perfmap

When a symbol lies within a module, and that module doesn't have
debuginfo (or doesn't even have an ELF header), the symbol will
always be resolved as [unknown]. However, the /tmp/perf-PID.map
(perf map) for that process might actually have an entry for that
symbol, if it was dynamically generated by some external tool.
This commit changes the resolution process such that if the desired
address lies in a module but that module doesn't have debuginfo,
we keep trying to resolve it in subsequent modules (including the
perf map). If we resolve it successfully using the perf map, the
reported symbol information will have the original module's name,
so we don't lose fidelity.

The motivation for this change is the way symbols work with .NET
Core on Linux. The runtime binaries are compiled ahead-of-time to
native code, but do not have debuginfo. There is an external tool,
which generates a file similar to a perf map (albeit with relative
addresses) for these binaries. This file can then be merged into
the main perf map for the process and used for symbol resolution,
but only if we keep trying to use the perf map when the symbol is
in a previously-seen module.

Merge pull request #997 from markdrayton/perf-buffer-size

Make perf ring buffer size configurable

Make perf ring buffer size configurable

As discussed in #966, this PR makes the size of the ring buffer used to send
data to userspace configurable. It changes the Python, Lua and C++ APIs to
expose this knob.

It also defaults the buffer size to a larger value (64 pages per CPU, an 8x
increase) for several tools which produce a lot of output, as well as making it
configurable in `trace` via a `-b` flag.

Merge pull request #1003 from ColinIanKing/master

snapcraft: add in some new tools missing from the snapcraft apps list

Merge pull request #1008 from pchaigno/support-macro

Support for macros in rewriter

Support for macros in rewriter

Extends the scope of 98b90974625's fix to support macros anywhere in the
rewriter. All SourceRange objects are replaced to use macro expanded locations.

Merge pull request #994 from qmonnet/kernelfeatures

docs: Update eBPF features list

docs: Update eBPF features list

Update of BPF features list, following the release of kernel 4.10.

snapcraft: add in some new tools missing from the snapcraft apps list

Add in syscount, dbstat and dbslower to apps list.

Signed-off-by: Colin Ian King <colin.king@canonical.com>

cc: Handle nested functions correctly when resolving symbols

`ProcSyms::Module::find_addr` incorrectly resolves symbols when
functions are nested in each other. Specifically, this was discovered
with libpthread, where there are multiple symbols for `write`,
where `write_nocancel` is strictly nested inside `write`. Fix by
explicitly going backward until we reach a matching symbol -- see
details in `ProcSyms::Module::find_addr` comments.

Merge pull request #999 from markdrayton/perf-map-anon

Improve matching of file-backed memory mappings

Improve matching of file-backed memory mappings

Use the same rules as perf to determine if a mapping in /proc/pid/maps is
file-backed. This allows mappings in anonymous huge pages and so on to fall
back to resolving from /tmp/perf-pid.map, if appropriate.

ref: http://lxr.free-electrons.com/source/tools/perf/util/map.c#L28

Merge pull request #996 from markdrayton/fix-find-buildid

Fix "for loop initial declarations only in C99" compile error

Merge pull request #995 from pchaigno/patch-1

Fix minor error in test instructions

Fix "for loop initial declarations only in C99" compile error

Fix error in test instructions

Merge pull request #967 from goldshtn/debuginfo

External debuginfo support and general symbols overhaul

tests: Test debuginfo through debuglink and build-id sections

This commit introduces support for tests of the new debuglink and
build-id debuginfo resolution functionality. The tests build a
dummy.c file with a debuglink section, and again with a build-id
section, and make sure that the symbol resolution code can locate
the debug information correctly (in the binary's directory for
debuglink, and in /usr/lib/debug/.build-id for the build-id).

Fix symbol resolution by name (SymbolCache.resolve_name)

The implementation of `ProcSyms::resolve_name` was only valid for
kernel symbols, when there is no module. When a module was provided,
it would segfault due to the module being null. Fixed by making
`bcc_symcache_resolve_name` take an additional module parameter,
which, for kernel symbols, is simply null (`None` from Python).

cc: Resolve symbols from external debuginfo

Adds support for resolving symbols using external debuginfo files,
which can be retrieved from two locations. First, check the build-id
of the desired binary and look in /usr/lib/debug/.build-id according
to the build-id structure. Second, check the debuglink section of
the desired binary and look in /usr/lib/debug or in the binary's
current directory. These are the rules applied by GDB as well, but
GDB lets the user reconfigure the debug directory path from
/usr/lib/debug to something else; we do not support this.

These changes are based on the following description of how GDB
resolves external debuginfo:

https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

cc: Correctly treat PIE files as shared objects for symbols

When resolving symbols, ProcSyms would treat position-independent
executables (PIE files) incorrectly, resulting in symbol resolution
failures. Specifically, PIE files are treated like shared objects
for ASLR, which means all symbol addresses in the file need to be
taken relative to the executable load address at runtime, the same
as with dynamic library shared objects.

The fix is in the `is_so()` method on `ProcSyms::Module`, which
now uses the correct `bcc_elf_is_shared` helper for testing if a
file is a shared object rather than just looking at the extension
".so", which is very brittle -- and wrong.

trace: Migrate to new symbols API and remove addresses from stacks

off{cpu,wake}time: Migrate to new symbols API and remove addresses

Remove addresses from stack output, as these are not used in the
vast majority of the cases.

uthreads: Migrate to new symbols API and include module name

stacksnoop: Migrate to new symbols API and remove addresses

stackcount: Migrate to new symbol resolution API