1. 05 Mar, 2017 1 commit
    • Paul Chaignon's avatar
      Fix bpf_dins_pkt rewrite in BinaryOperator · 47b74fe0
      Paul Chaignon authored
      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.
      47b74fe0
  2. 04 Mar, 2017 3 commits
  3. 03 Mar, 2017 8 commits
    • Brenden Blanco's avatar
      Merge pull request #1018 from GabrielGanne/python-xdp-return-values · b69fe977
      Brenden Blanco authored
      add XDP return values to python interface
      b69fe977
    • Sasha Goldshtein's avatar
      cc: Symbol resolution with multiple executable regions per module · f141d1b9
      Sasha Goldshtein authored
      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.
      f141d1b9
    • Sasha Goldshtein's avatar
      cc: Fix assertion for debug builds · 9ca8ac28
      Sasha Goldshtein authored
      9ca8ac28
    • Rafael F's avatar
      range Python 2 -> 3 compatibility (#983) · d7a5ff09
      Rafael F authored
      d7a5ff09
    • Rafael F's avatar
      usdt: fix argument passing on python3 (#984) · 1a1f441f
      Rafael F authored
      This fixes the following error:
      
      $: ./tplist -v -v -l /usr/lib64/dri/i965_dri.so
      argument 1: <class 'TypeError'>: wrong type
      1a1f441f
    • Alan Thompson's avatar
      Update tutorial_bcc_python_developer.md (#1017) · 8ef6eb8d
      Alan Thompson authored
      small typo
      8ef6eb8d
    • Brenden Blanco's avatar
      Merge pull request #1020 from goldshtn/duplicate_modules · 71600e70
      Brenden Blanco authored
      cc: Don't parse the same module multiple times for USDT probes
      71600e70
    • Sasha Goldshtein's avatar
      cc: Don't parse the same module multiple times for USDT probes · 69948a69
      Sasha Goldshtein authored
      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.
      69948a69
  4. 02 Mar, 2017 3 commits
  5. 01 Mar, 2017 1 commit
  6. 28 Feb, 2017 5 commits
    • 4ast's avatar
      Merge pull request #1012 from goldshtn/buildid-fix · 4d0d4308
      4ast authored
      cc: Fix SEGV when there is no build-id section
      4d0d4308
    • 4ast's avatar
      Merge pull request #1014 from iovisor/test-debuginfo-fix · 88abfc68
      4ast authored
      Fix long running test_debuginfo and python3 fix
      88abfc68
    • Brenden Blanco's avatar
      Fix long running test_debuginfo and python3 fix · 7b35436a
      Brenden Blanco authored
      Make sure subclass calls super().tearDown to clean up dummy process.
      Also, fixup a python3 str.encode().
      
      Fixes: #1013
      Signed-off-by: default avatarBrenden Blanco <bblanco@gmail.com>
      7b35436a
    • Sasha Goldshtein's avatar
      cc: Retry symbol resolution using perfmap · 8a3fb6cc
      Sasha Goldshtein authored
      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.
      8a3fb6cc
    • Brenden Blanco's avatar
      Merge pull request #997 from markdrayton/perf-buffer-size · 3febfa49
      Brenden Blanco authored
      Make perf ring buffer size configurable
      3febfa49
  7. 27 Feb, 2017 1 commit
    • Mark Drayton's avatar
      Make perf ring buffer size configurable · 5f5687e4
      Mark Drayton authored
      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.
      5f5687e4
  8. 26 Feb, 2017 3 commits
  9. 23 Feb, 2017 4 commits
  10. 22 Feb, 2017 2 commits
  11. 21 Feb, 2017 9 commits