1. 20 Apr, 2016 8 commits
    • Vicent Marti's avatar
      lua: Remove unused files · 15867d32
      Vicent Marti authored
      The `sym` module no longer needs to be exported. The `LD` module is no
      longer used anywhere.
      15867d32
    • Vicent Marti's avatar
      lua: Use the new native Symbol resolver · 55d75ca8
      Vicent Marti authored
      The static `BPF.SymbolCache` now uses a native symbol resolver instead
      of the Lua/binutils implementation. Likewise for the kernel symbol
      resolver, and the `check_path_symbol` API to find a probe's hook
      address.
      55d75ca8
    • Vicent Marti's avatar
      lua: Wrap the new native APIs · 664249b7
      Vicent Marti authored
      664249b7
    • Vicent Marti's avatar
      cc: Add a native Symbol Resolver cache · be4072a1
      Vicent Marti authored
      This new set of C/C++ APIs is capable of performing symbol resolution
      for any given running process, using the native `libelf` APIs instead of
      shelling out to binutils tools.
      
      This is a reimplementation of the original ProcSyms Python/Lua code.
      be4072a1
    • Vicent Marti's avatar
      cc: Add a set of process utils written in C/C++ · b366ede5
      Vicent Marti authored
      These APIs mimic behavior that was being performed using native tools.
      
      - bcc_procutils_which_so: resolves a short library name into a full path
        so a shared object. Equivalent to `ldconfig -p`
      - bcc_procutils_which: resolves a short name into a full path to a
        binary. Equivalent to a shell's builtin `which`
      - bcc_procutils_each_module: lists all the modules loaded in a process'
        memory space. Uses the kernel's `/proc/$pid/maps`
      - bcc_procutils_each_ksym: lists all symbols and addresses for the
        kernel. Uses the kernel's `/proc/kallsyms`
      b366ede5
    • Vicent Marti's avatar
      cc: Add a set of ELF-related APIs based on libelf · b8f0f092
      Vicent Marti authored
      The following APIs have been implemented inside `libbcc`, which
      programatically replicate the previous usage of `binutils` tools like
      `objdump` and `elfdump`.
      
      - bcc_elf_foreach_usdt: finds all USDT probes inside a given binary
      - bcc_elf_loadadddr: find the load address for a shared object
      - bcc_elf_foreach_sym: lists all symbols in an ELF binary or SO
      - bcc_elf_shared_obj: returns whether a given path is an ELF shared
        object, a binary, or neither
      b8f0f092
    • Vicent Marti's avatar
      cmake: Add dependency to LibELF · 0612db5f
      Vicent Marti authored
      Add a new a `FindLibElf.cmake` package, and use it to link the main
      `libbcc` library against the system's LibELF. This library will be used
      to re-implement functionality that was previously dependent on
      `binutils`.
      0612db5f
    • Vicent Marti's avatar
      cmake: Properly use library detection modules · ff9ff5d6
      Vicent Marti authored
      Instead of importing the `Find*.cmake` modules directly, place them in
      the root `cmake/` folder and define it as a CMake Module path. This lets
      us use the `find_package` builtin to require any given packages.
      ff9ff5d6
  2. 19 Apr, 2016 7 commits
  3. 18 Apr, 2016 2 commits
  4. 17 Apr, 2016 3 commits
  5. 16 Apr, 2016 1 commit
    • Aaron Puchert's avatar
      Don't require "OS ABI" specification in libraries · 3926f264
      Aaron Puchert authored
      The most important system libraries are listed like this by ldconfig:
      
      	libc.so.6 (libc6,x86-64, OS ABI: Linux 3.0.0) => /lib64/libc.so.6
      
      But most user-level libraries don't have the "OS ABI" and will not be
      found by the regular expression.
      
      	libz.so (libc6,x86-64) => /usr/lib64/libz.so
      
      This makes the regular expression more permissive, so that it finds
      those libraries as well.
      3926f264
  6. 15 Apr, 2016 1 commit
    • Vicent Marti's avatar
      lua: Properly support high-range 64 addresses · fbf7193c
      Vicent Marti authored
      Lua's native Number type is a 64-bit double with 52-bit precision, which
      was causing rounding errors when storing and working with high-range
      memory addresses (namely, addresses from the kernel, which are all in
      the `0xffffffff........` range).
      
      To work around this, we've made sure to never call `tonumber` on any
      variables that represent memory addresses, and instead continue
      operating on them with their native types: LuaJIT can work with the
      underlying `uint64_t` type for these values and transparently perform
      all kinds of numeric operations.
      
      The only limitation of working with native 64-bit types in LuaJIT is
      that they cannot be printed with the language's default `string.format`
      API. To give better UX to probe writers, these APIs have been
      monkeypatched so the `%p` format specifier will now properly handle
      64-bit addresses and print them in an appropriate format.
      fbf7193c
  7. 14 Apr, 2016 1 commit
  8. 11 Apr, 2016 2 commits
  9. 10 Apr, 2016 5 commits
  10. 09 Apr, 2016 2 commits
  11. 06 Apr, 2016 6 commits
  12. 05 Apr, 2016 2 commits