| Age | Commit message (Collapse) | Author |
|---|
|
* Make dependency on LLVM native target optional
Adds an option ENABLE_LLVM_NATIVECODEGEN with default value ON.
If set to off the "nativecodegen" llvm will not be enabled, thus
reducing dependencies on needed libraries (reduced text size when
building with statically linked libraries).
Code that uses native target will not be compiled reducing text size.
Currently this affects the rw_engine which needs the native target.
BPF api "rw_engine_enabled" will have default value "true" if
ENABLE_LLVM_NATIVECODEGEN="ON" and "false" if
ENABLE_LLVM_NATIVECODEGEN="OFF"
Not needed for BCC to work. It somehow brought in the interpreter and
executionengine which is needed. Those features are added instead.
* Remove garbage in code making it compile again
* Remove interpreter and executionengine LLVM dependencies
These doesn't seem to be needed on a Ubuntu 18.04 system (although
executionengine is heavily used).
Interpreter was added due to runtime dependency on ARM64. It brings in
a dependency on ffi library.
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x3a): undefined reference to `ffi_type_float'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x43): undefined reference to `ffi_type_void'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x53): undefined reference to `ffi_type_pointer'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x63): undefined reference to `ffi_type_double'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x78): undefined reference to `ffi_type_sint8'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x83): undefined reference to `ffi_type_sint16'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0x93): undefined reference to `ffi_type_sint64'
(.text._ZL10ffiTypeForPN4llvm4TypeE+0xb3): undefined reference to `ffi_type_sint32'
/usr/lib/llvm-6.0/lib/libLLVMInterpreter.a
|
|
In llvm/clang 8 trunk, the following commits
https://reviews.llvm.org/rL339384
https://reviews.llvm.org/rL339385
https://reviews.llvm.org/rL339386
renames getLocStart to getBeginLoc, and getLocEnd to getEndLoc.
This caused bcc compilation error with llvm/clang 8.
To avoid proliferation of #define's based on LLVM version numbers
and similar logic for many different types,
this patch fixed the issues by define macros in common
frontend_action_common.h where macro definition is multi-versioned
based on llvm version. The macro itself is used in
{b,tp}_frontend_action.cc.
clang 8 also introduced a new library dependency
libclangAnalysis.a depends on libclangASTMatchers.a
This patch fixed this issue as well.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
* tools: use printb for more python3 compat
Switch to printb in killsnoop and wakeuptime
* tests: use subproceess sleep to trigger test
In some python implementations, time.sleep uses select instead of
nanosleep and hence won't trigger the bpf kprobe.
* tools: remove explicit python3 shebang
Use an ambiguous python invocation in the shebang line. Instead, rely on
packaging stage to mangle the line to specify a python version.
* cmake: add ENABLE_LLVM_SHARED option
This adds an option to specify that only the dynamic libraries should be
used to link bcc. This is most likely to be used in systems that don't
build/provide the llvm-static and clang-static package options
(fedora-based).
* rpm: enable llvm_shared and python3 build options
Enable rpm packaging with two new features:
- shared-only packaging (no static linking)
- python3
To enable these build features (off by default), run:
RPM_WITH_OPTS="--with llvm_shared --with python3" ./scripts/build-rpm.sh
* rpm: protect python3-bcc package declaration
Don't define python3-bcc if --with python3 isn't explicitly specified.
* specs: only build python3 if requested
* man: compress man pages
* specs: enable python3 by default in fc28+/rh8+
- Enable llvm_shared and python3 --with options by default in new fedora
- Fix string quoting
- Update spec changelog
|
|
Fix issue #1502.
A few cmake version checking greater than 5 includes 5.0.1
which results in compilation failure. Change version checking
to explicitly equal to or greater than version 6.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
The linux arm64 header linux:arch/arm64/include/asm/sysreg.h
contains asm statement outside the function,
========
asm(
" .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
" .equ .L__reg_num_x\\num, \\num\n"
" .endr\n"
" .equ .L__reg_num_xzr, 31\n"
"\n"
" .macro mrs_s, rt, sreg\n"
__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
" .endm\n"
"\n"
" .macro msr_s, sreg, rt\n"
__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
" .endm\n"
);
========
The compiler cannot remove them since they are file scope.
This patch adds bpf asm parser to handle this, otherwise,
llvm will complain with compilation failure. Since none of
macros/defines are used in bpf program, there is no impact
in compilation result.
Another change is to add AARCH64 value to ld_cache processing.
The value is taken from glibc:sysdeps/generic/ldconfig.h.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
The patch adds a new debug option "DEBUG_SOURCE = 8" to
dump insns embedded with source. In C++ API, users
can change BPF constructor "flag" value to enable debug output.
In Python API, users can change "debug" value to enable
debug output. For example, for python test program test_usdt.py,
the debug output looks like below:
......
Disassembly of section .bpf.fn.do_trace1:
do_trace1:
; int do_trace1(struct pt_regs *ctx) { // Line 110
0: bf 16 00 00 00 00 00 00 r6 = r1
1: b7 01 00 00 00 00 00 00 r1 = 0
; struct probe_result_t1 result = {}; // Line 111
2: 7b 1a f0 ff 00 00 00 00 *(u64 *)(r10 - 16) = r1
; switch(ctx->ip) { // Line 5
3: 79 61 80 00 00 00 00 00 r1 = *(u64 *)(r6 + 128)
4: 15 01 04 00 d7 06 40 00 if r1 == 4196055 goto 4
5: 55 01 06 00 ce 06 40 00 if r1 != 4196046 goto 6
; case 0x4006ceULL: *((int8_t *)dest) = ctx->ax; __asm__ __volatile__("": : :"memory"); return 0; // Line 6
6: 79 61 50 00 00 00 00 00 r1 = *(u64 *)(r6 + 80)
......
For asm insns, byte code is also dumped out (similar to objdump).
For source codes, only lines in the module file are printed (as expected).
The line number is added at the end of source code, which is
especially helpful for inlined functions.
This functionality is only in llvm 6.x (the trunk version), which
provides an public interface to create a dwarf context based on
a set of in-memory debug sections. llvm 5.x also provides
such a public interface in a different way, and this patch
does not support it in bcc yet. llvm 4.x and lower do not
have such a public interface and hence will not be supported
in bcc.
In this patch, the debug output only goes to stderr.
A subsequent patch will dump the per-function output into
<BCC_PROG_TAG_DIR>/bpf_prog_<tag>/ if it is available.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
The bug does not show up in my previous test probably because
I did not clean up the build directory and did not have a clean cmake.
In gcc 4.8.5 environment where -no-pie is not supported,
a clean cmake will trigger the issue as subsequent other
cxx compile test will fail due to additional -no-pie flag.
The fix is to reset the CMAKE_REQUIRED_FLAGS to its previous value
after the specific test.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
Move two usdt related files to a new subdirectory and link them into the
final product. Introduce a cmake option to disable that feature (turning
it off currently fails to compile).
Move some of the cmake flag computation into a helper cmake file and
include that rather than inlining it.
Signed-off-by: Brenden Blanco <bblanco@gmail.com>
|
|
Certain versions of recent gcc (e.g., gcc 6.3.0 on ubuntu17.04)
has pie enabled by default at linker (collect2) stage.
The compilation flag "-no-pie" is available to negate
this linker option.
Add -no-pie to compilation flag only if it is available.
Earlier gcc compiler may not have this option but it does
not have linker pie on-by-default either.
Tested with ubuntu 17.04 and my local gcc 4.8.5 (not accepting -no-pie).
Signed-off-by: Yonghong Song <yhs@fb.com>
|
|
I don't think the current way cmake uses to locate the correct lua.h
works. Entries like "include/foo.h" cause cmake to look for a file
like "/usr/include/include/foo.h". I.e., the include/ prefix for
all the entries is wrong as is adding "include" at the end.
This patch removes the prefix. With it bcc finally compiles on
Fedora.
If this change causes a problem there is something seriously wrong
with cmake.
|
|
Some Linux distributions (at least Fedora and RHEL) do not provide
libluajit as an archive and instead only as a DSO. Using the DSO
does not have any negative impact but the cmake script does not
check for the DSO files and instead fails to find luajit.
This simple change causes cmake to find the file as named in the
above distributions. Maybe more change or a generalized method are
needed in future. The prefered way to detect the DSO for Fedora/RHEL
would be to use pkgconfig but I don't propose to use it at this time.
|
|
|
|
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`.
|
|
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.
|
|
|
|
These fixes are manually included in the released 0.1.7 packages, but
will help with future builds.
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
|
|
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
|
