Describe the bug

make build exit with error. Need more prompting message.
To Reproduce

git clone bpftime, and just make build.
Expected behavior

Maybe some prompting information is needed if the build environment not ready.
Screenshots

$ make build
cmake -Bbuild -DBPFTIME_ENABLE_UNIT_TESTING=1
-- Enabling ubsan for Debug builds; Processor=x86_64
-- Started CMake for bpftime v0.1.0...

CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:1721 (file):
  file problem creating directory:
  /home/pdliyan/bpftime/third_party/libbpf//src
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3633 (_ep_set_directories)
  cmake/libbpf.cmake:6 (ExternalProject_Add)
  CMakeLists.txt:63 (include)


CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:1723 (message):
  dir '/home/pdliyan/bpftime/third_party/libbpf//src' does not exist after
  file(MAKE_DIRECTORY)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3633 (_ep_set_directories)
  cmake/libbpf.cmake:6 (ExternalProject_Add)
  CMakeLists.txt:63 (include)


-- Configuring incomplete, errors occurred!
See also "/home/pdliyan/bpftime/build/CMakeFiles/CMakeOutput.log".
make: *** [Makefile:48: build] Error 1

Desktop (please complete the following information):

• OS: Centos
• Version 8
  CentOS Linux release 8.4.2105

Additional context

In the future, we may need complex configurations for bpftime (both agent and server and daemon). Configurations may be provided from multiple sources, such as config files or env vars. Find a way to process them

In addition to current u(ret)probe support, it would be useful to support USDT.

Describe the solution you'd like

Support libbpf and bpftrace's usdt

Describe alternatives you've considered

Not quite sure. Maybe the current uprobe support can support usdt as well?

Provide usage examples

Trace usdt (such as the DTrace probes in OpenJDK https://github.com/openjdk/jdk/blob/e44276989fc6358065412be7567d0141c84f1282/src/hotspot/os/posix/dtrace/hotspot.d#L4)

Is your feature request related to a problem? Please describe.

Please help us port and test more examples from https://github.com/iovisor/bcc/tree/master/libbpf-tools

Describe the solution you'd like

Put examples in https://github.com/eunomia-bpf/bpftime/tree/master/example/libbpf-tools.

examples/malloc cannot work as expected, i.e elements in the map was not successfully updated. Userspace program can't retrive elements put by the ebpf program.

How to reproduce

Follow https://github.com/eunomia-bpf/bpftime/tree/master/example/malloc to run. Note 31eb300 should be used.

Description:
The current benchmarking approach might be providing misleading results due to the inclusion of certain functions that induce context switching. For instance, current system calls (syscalls) include print functions which overshadow the minor performance differences, as the results are mostly in the order of milliseconds (ms). However, the difference in eBPF programs for syscall tracepoints might just be a few hundred nanoseconds (ns).

Proposed Solutions:

1. Decompose the Benchmark into Multiple Cases: The benchmark should be divided into distinct cases to evaluate the impact of each segment on performance.
   • Syscall Tracepoint Benchmark: This benchmark should only focus on syscall tracepoints. It can include a very simple arithmetic operation like (a+b) to prevent it from being optimized away. This will help in calculating the inherent overhead of syscall tracepoints.
   • Hashmaps Benchmark: This case should measure the time taken for hashmap operations. It should include a helper function to retrieve the PID and use hashmaps for statistics.
   • LLVM JIT Performance: Test the performance of the LLVM JIT with slightly complex calculations to understand its impact.

Note: If implementing the above solutions is cumbersome, consider creating an issue for future reference and revisit it later.

Due to the strange behavior of bpftime when forking/exec-ing, it's hard to automatically test bashreadline use pipe + subprocess. Find a better way to test it

Describe the bug

$ sudo ~/.bpftime/bpftime  start -s example/libbpf-tools/opensnoop/opensnoop
...
2185   node              21   0 /proc/24936/cmdline
2185   node              21   0 /proc/24856/cmdline
2185   node              21   0 /proc/24936/cmdline
2185   node              21   0 /proc/24856/cmdline
2185   node              21   0 /proc/24936/cmdline
2185   node              21   0 /proc/24856/cmdline
2185   node              21   0 /proc/24936/cmdline
2185   node              21   0 /proc/24856/cmdline
^CSegmentation fault

To Reproduce

run

$ sudo ~/.bpftime/bpftime  load example/libbpf-tools/opensnoop/opensnoop

and run:

$ sudo ~/.bpftime/bpftime  start -s example/libbpf-tools/opensnoop/opensnoop

Expected behavior

Screenshots

Desktop (please complete the following information):

• OS: [e.g. Windows]
• Version [e.g. 10]

Additional context

Hi,

I attended the bpftime talk at LPC last week. It was a very good talk and I was excited to try it with https://github.com/spdk/spdk - a project where I am a core maintainer.

SPDK is a high-performance user space storage application framework. It has its own tracing capability. We have tried to use bpftrace with SPDK, but the overhead of the context switches is too high to instrument high-performance IO paths. So we primarily use bpftrace for control paths, and rely on the native SPDK tracing for instrumenting high-performance IO paths.

So bpftime is something we are very interested in. Unfortunately our initial testing (seen both by me and @ksztyber) is that bpftime + bpftrace actually performed worse than bpftrace by itself. We are hoping the bpftime community could help explain what we are seeing, including anything we may have done wrong with our configuration.

Reproduction steps:

First, clone SPDK:

git clone https://github.com/spdk/spdk
git submodule update --init

Install dependencies:

cd spdk
scripts/pkgdep.sh

Build SPDK:

./configure --with-usdt
make -j

Paste the following into a file named null.json. This is the configuration for a null block device which will be used for the test:

{
  "subsystems": [
    {
      "subsystem": "bdev",
      "config": [
        {
          "method": "bdev_null_create",
          "params": {
            "name": "null0",
            "num_blocks": 2048000,
            "block_size": 512,
            "physical_block_size": 512,
            "md_size": 0,
            "dif_type": 0,
            "dif_is_head_of_md": false,
            "uuid": "38c40683-88fe-446b-8db0-6b815396b2e7"
          }
        },
        {
          "method": "bdev_wait_for_examine"
        }
      ]
    }
  ]
}

Try running the SPDK bdevperf test without any probes. The test will run for 5 seconds, and then should show somewhere between 10M and 20M IOPs depending on your platform (it is 13.9M IO/s on my system):

build/examples/bdevperf -w randread -o 4096 -q 16 -t 5 -c null.json

Now start bpftrace by itself, and run bdevperf (note, I couldn't get the bdevperf app to terminate correctly running it as an argument to bpftrace -c):

bpftrace -e 'uprobe:/home/jimharris/git/spdk/build/examples/bdevperf:spdk_bdev_io_complete { @completed = count(); }' &
build/examples/bdevperf -w randread -o 4096 -q 16 -t 5 -c null.json
fg
^C

On my Xeon system, this drops the performance to about 1.6M IO/s.

Now with bpftime:

bpftime load bpftrace -- -e 'uprobe:/home/jimharris/git/spdk/build/examples/bdevperf:spdk_bdev_io_complete { @completed = count(); }'
# now in other terminal
bpftime start build/examples/bdevperf -- -w randread -o 4096 -q 16 -t 5 -c null.json

On my Xeon system, this further drops the performance to about 360K IO/s.

Please let us know if there is anything we can do to help explain this.

Thanks,

Jim Harris

Describe the bug

bpftrace doesn't terminating correctly, it does't response with Ctrl C.

reproduce:

1. Install bpftrace with package manager: apt install bpftrace
2. Run bpftrace

sudo SPDLOG_LEVEL=error ~/.bpftime/bpftime load bpftrace -- -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

Expected behavior

Ctrl C will perform correctly.

Is your feature request related to a problem? Please describe.

Current only opensnoop and malloc can work as a example. Others cannot because perf event output is not implemented yet.

We should fix it.

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

bpf_tail_call has the same semantic as execl(2). Now we want to implement kernel->userspace tail call, means that a kernel ebpf program could call bpf_tail_call and jumps to a userspace program.

Describe the bug

Run benchmark in multi-thread will result in significant performance overhead:

$ LD_PRELOAD=build/runtime/agent/libbpftime-agent.so benchmark/test

Benchmarking __benchmark_test_function1 in thread 1
Average time usage 1.351700 ns, iter 100000 times

Benchmarking __benchmark_test_function2 in thread 1
Average time usage 5.864650 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 1
Average time usage 288.789940 ns, iter 100000 times

INFO [156136]: Global shm destructed
$ LD_PRELOAD=build/runtime/agent/libbpftime-agent.so benchmark/test 8
...
Benchmarking __benchmark_test_function3 in thread 8
Average time usage 1294.628970 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 3
Average time usage 1338.905010 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 8
Average time usage 1671.551980 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 8
Average time usage 1685.110550 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 4
Average time usage 2021.452540 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 8
Average time usage 1881.932160 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 8
Average time usage 1442.957710 ns, iter 100000 times

Benchmarking __benchmark_test_function3 in thread 1
Average time usage 1837.997850 ns, iter 100000 times

INFO [151866]: Global shm destructed

See the discussion in #97. The test driver is in #103.

Expected behavior

There should be no lock, no syscalls in our hot path. We should try our best to optimize the overhead.

Is your feature request related to a problem? Please describe.

Add kernel ring buffer and perf event support for kernel-user maps

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

Is your feature request related to a problem? Please describe.

We need more documents:

• Description of how to use bpftime for uprobe, syscall tracing
• The details of how bpftime works

Describe the solution you'd like

Add documents in eunomia.dev

Describe alternatives you've considered

Provide usage examples

Additional context

Is your feature request related to a problem? Please describe.

As discussed before, we need to use kernel eBPF runtime if the prog access kernel data structures like task_struct.

We can use a syscall instead of trap, and may gain 2x less overhead because syscalls are more lightweight.

Describe the solution you'd like

See the kernel-vm branch for poc. We should find a better way to make it work with libbpf.

Describe alternatives you've considered

Provide usage examples

Additional context

Describe the bug
For example, using bash_readline,bpftime can properly catch the bashline,but it report Failed to initialize attach context

To Reproduce

1.go to example/bash_readline
2.bpftime load ./readline
3. start another shell and ensure the pid
4. start another shell type : bpftime attach pid or bpftime start /bin/bash

Expected behavior
Running properly.

Screenshots

Desktop (please complete the following information):

• OS: win11 WSL2 ubuntu:2204

Best regards.

The two workflows are duplicate. merge them, and migrate them to support running all examples

Describe the bug

FIx the CI

• add boost as deps
• fix libbpf link error
• fix test cases

To Reproduce

Expected behavior

Screenshots

Desktop (please complete the following information):

• OS: [e.g. Windows]
• Version [e.g. 10]

Additional context

The invocation listener of frida gum has some performance issue:

##g_array_set_size

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ns/call  ns/call  name    
 51.28      0.20     0.20                             _frida_g_array_set_size
 15.38      0.26     0.06                             _gum_function_context_begin_invocation
  7.69      0.29     0.03                             main
  5.13      0.31     0.02                             _gum_function_context_end_invocation
  5.13      0.33     0.02                             _init
  5.13      0.35     0.02                             gum_invocation_stack_push
  5.13      0.37     0.02                             plus

According to my test, call to g_array_set_size takes half time of the whole run.

With more investigation, the call to this function happens at gum_invocation_stack_push and gum_invocation_stack_pop, where frida gum uses g_array to maintain a call stack, and will push or pop elements from the stack when entering _gum_function_context_begin_invocation or _gum_function_context_begin_invocation. So g_array_set_size will be called at least twice each time the hooked function was called.

According to the implementation listed:

• https://github.com/frida/glib/blob/638b2073275bf1fde72b02bf507ef66c1f79743b/glib/garray.c#L704
• https://github.com/frida/glib/blob/638b2073275bf1fde72b02bf507ef66c1f79743b/glib/garray.c#L835
• https://github.com/frida/glib/blob/638b2073275bf1fde72b02bf507ef66c1f79743b/glib/garray.c#L163

A memset might be used to clean the extra elements, so I think this is one of the cause of the performance issues.

Output of perf top also proves this

pthread_setspecific

Test with multiple threads, pthread_setspecific costs 14.09% of total instruction reads, which is even more than _gum_function_context_begin_invocation itself.

--------------------------------------------------------------------------------
Ir                      
--------------------------------------------------------------------------------
19,585,761,005 (100.0%)  PROGRAM TOTALS

--------------------------------------------------------------------------------
Ir                      file:function
--------------------------------------------------------------------------------
2,760,002,940 (14.09%)  ./nptl/./nptl/pthread_setspecific.c:pthread_setspecific@@GLIBC_2.34 [/usr/lib/x86_64-linux-gnu/libc.so.6]
2,660,000,000 (13.58%)  frida/build/tmp-linux-x86_64/frida-gum/../../../frida-gum/gum/guminterceptor.c:_gum_function_context_begin_invocation [/root/frida-gum-test/a.out]
2,180,070,385 (11.13%)  ./gmon/./gmon/mcount.c:__mcount_internal [/usr/lib/x86_64-linux-gnu/libc.so.6]
2,000,054,740 (10.21%)  ./gmon/../sysdeps/x86_64/_mcount.S:mcount [/usr/lib/x86_64-linux-gnu/libc.so.6]
1,640,000,000 ( 8.37%)  frida/build/tmp-linux-x86_64/frida-gum/../../../frida-gum/gum/guminterceptor.c:_gum_function_context_end_invocation [/root/frida-gum-test/a.out]
1,580,020,848 ( 8.07%)  ???:main::{lambda()#1}::operator()() const'2 [/root/frida-gum-test/a.out]
1,120,000,000 ( 5.72%)  ???:0x0000000005325208 [???]

pthread_setspecific and pthread_getspecific and APIs to read and write thread local variables, frida gum uses them (and g_private, which also calls the posix apis) to maintain a per-thread state, and access them frequently in invocation begin and end.

Output of perf top proves this

Atomic instructions

In the implementation of _gum_function_context_begin_invocation, an atomic instruction lock incl (%rax) takes about 25% time usage of the function

When using multiple threads (20), atomic instructions cause larger performance decrease:

Is your feature request related to a problem? Please describe.

currently we have types for BPF_TYPE_UPROBE_OVERRIDE and BPF_TYPE_UPROBE, implemented with different mechanism. I think there is no need to keep them both. We can just make the uprobe able to use bpf_override_return.

Describe the solution you'd like

remove BPF_TYPE_UPROBE_OVERRIDE and make BPF_TYPE_UPROBE using frida replace.

Describe alternatives you've considered

Is it better not to change them? I'm not sure.

While doing my work related to issue #97, I've noticed that SIGINT (Ctrl-C) doesn't terminate the 'bpftime load' execution.

I'm testing with recent master, commit 761467c.

We need a new framework to run unit tests and integrated tests.

Some notes:

• Use Catch2 to run unit tests. Examples could be seen at /bpftime-verifier
• Unit tests of a certain sub-project should be linked into a single executable
• Tests should be full-automatically executed, meaning that things from building and spraying ebpf programs to running the executables should be done by the build system, or something else. We already have a cmake function add_ebpf_program_target that could adds a target to build ebpf program. Make use of this, such as passing the path of already-built ebpf program to the test programs through macro definition. benchmark/simple-benchmark-with-embed-ebpf-calling uses this way

Add & adapt an example that contains the mixed usage of kprobe and uprobe (a simplified situation of deepflow, since deepflow is hard to debug), also the using of shared maps (hash, array, perf event array, etc)

See https://github.com/eunomia-bpf/bpftime/actions/runs/6874766716/job/18697158968

The symbol syscall_addr was defined in inline assembly in text_segment_transformer.cpp

When BPFTIME_ENABLE_LTO was set, a symbol not found error will be raised when trying to use the build products. Seems that when enabling LTO, the symbol was dropped. Find a way to keep the symbol when using LTO

Describe the bug

make release reports error.

To Reproduce

cd bpftime && make release

Expected behavior

Screenshots

gmake[3]: Entering directory '/home/pdliyan/bpftime/build'
[ 95%] Linking CXX executable bpftime_daemon
../runtime/libruntime.a(bpftime_shm_internal.cpp.o): In function `bpftime_remove_global_shm':
bpftime_shm_internal.cpp:(.text+0x4223): undefined reference to `shm_unlink'
../runtime/libruntime.a(bpftime_shm_internal.cpp.o): In function `bpftime::bpftime_shm::bpftime_shm(char const*, bpftime::shm_open_type)':
bpftime_shm_internal.cpp:(.text+0xc9dd): undefined reference to `shm_unlink'
../runtime/libruntime.a(bpftime_shm_internal.cpp.o): In function `boost::interprocess::shared_memory_object::shared_memory_object(boost::interprocess::open_only_t, char const*, boost::interprocess::mode_t)':
bpftime_shm_internal.cpp:(.text._ZN5boost12interprocess20shared_memory_objectC2ENS0_11open_only_tEPKcNS0_6mode_tE[_ZN5boost12interprocess20shared_memory_objectC5ENS0_11open_only_tEPKcNS0_6mode_tE]+0xa1): undefined reference to `shm_open'
../runtime/libruntime.a(bpftime_shm_internal.cpp.o): In function `void boost::interprocess::ipcdetail::managed_open_or_create_impl<boost::interprocess::shared_memory_object, 16ul, true, false>::priv_open_or_create<char const*, boost::interprocess::ipcdetail::create_open_func<boost::interprocess::ipcdetail::basic_managed_memory_impl<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index, 16ul> > >(boost::interprocess::ipcdetail::create_enum_t, char const* const&, unsigned long, boost::interprocess::mode_t, void const*, boost::interprocess::permissions const&, boost::interprocess::ipcdetail::create_open_func<boost::interprocess::ipcdetail::basic_managed_memory_impl<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index, 16ul> >)':
bpftime_shm_internal.cpp:(.text._ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_[_ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_]+0x138): undefined reference to `shm_open'
bpftime_shm_internal.cpp:(.text._ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_[_ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_]+0x295): undefined reference to `shm_open'
bpftime_shm_internal.cpp:(.text._ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_[_ZN5boost12interprocess9ipcdetail27managed_open_or_create_implINS0_20shared_memory_objectELm16ELb1ELb0EE19priv_open_or_createIPKcNS1_16create_open_funcINS1_25basic_managed_memory_implIcNS0_15rbtree_best_fitINS0_12mutex_familyENS0_10offset_ptrIvlmLm0EEELm0EEENS0_10iset_indexELm16EEEEEEEvNS1_13create_enum_tERKT_mNS0_6mode_tEPKvRKNS0_11permissionsET0_]+0x448): undefined reference to `shm_open'
collect2: error: ld returned 1 exit status
gmake[3]: *** [daemon/CMakeFiles/bpftime_daemon.dir/build.make:103: daemon/bpftime_daemon] Error 1
gmake[3]: Leaving directory '/home/pdliyan/bpftime/build'
gmake[2]: *** [CMakeFiles/Makefile2:813: daemon/CMakeFiles/bpftime_daemon.dir/all] Error 2
gmake[2]: Leaving directory '/home/pdliyan/bpftime/build'
gmake[1]: *** [Makefile:136: all] Error 2
gmake[1]: Leaving directory '/home/pdliyan/bpftime/build'
make: *** [Makefile:54: release] Error 2

Desktop (please complete the following information):

• OS: Centos
• Version 8
  CentOS Linux release 8.4.2105

Additional context

Not familiar with gmake, have to send this bug report.
With -lrt flag, my local test code with shm_open works okay.

#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>

int main() {
    // 创建或打开共享内存对象
    int fd = shm_open("/my_shared_memory", O_CREAT | O_RDWR, 0666);
    if (fd == -1) {
        perror("shm_open");
        return 1;
    }

    // 设置共享内存对象的大小
    if (ftruncate(fd, 1024) == -1) {
        perror("ftruncate");
        return 1;
    }

    // 将共享内存映射到进程的地址空间
    void* ptr = mmap(NULL, 1024, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (ptr == MAP_FAILED) {
        perror("mmap");
        return 1;
    }

    // 在共享内存中写入数据
    sprintf((char*)ptr, "Hello, shared memory!");

    // 解除内存映射
    if (munmap(ptr, 1024) == -1) {
        perror("munmap");
        return 1;
    }

    // 关闭共享内存对象
    if (close(fd) == -1) {
        perror("close");
        return 1;
    }

    // 删除共享内存对象
    if (shm_unlink("/my_shared_memory") == -1) {
        perror("shm_unlink");
        return 1;
    }

    printf("okay\n");

    return 0;
}

$ gcc -o sha_e shm.c -lrt && ./sha_e
okay

Is your feature request related to a problem? Please describe.

libbpf CO-RE should be able to work directly. We need to provide an example for it.

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

Is your feature request related to a problem? Please describe.

Use https://github.com/gabime/spdlog

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

Describe the bug

The current daemon exists a hack:

	// strncpy(obj->rodata->new_uprobe_path, env.new_uprobe_path, PATH_LENTH);
	// TODO: currently using `/a` as the replacing executable path to uprobe
	// perf event in the kernel, since long strings (such as bpftime_daemon it self)
	// may break userspace memory.
	// Find a better way to solve this in the future
	strncpy(obj->rodata->new_uprobe_path, "/a", PATH_LENTH);

This will make the uprobe failed if /a is not exist as an elf.

To Reproduce

run daemon

Expected behavior

1. can we found a better way to solve this?
2. Maybe we can create the /a file in advance?

Screenshots

Desktop (please complete the following information):

• OS: [e.g. Windows]
• Version [e.g. 10]

Additional context

Describe the bug
Attach /bin/bash cause segmentfault when testing gethostlatancy.
btw,when using attach -s, it will report [error][143913] Failed to initialize attach context

To Reproduce
1.using example/libbpf-tools/gethostlatancy
2.(root)bpftime load ./gethostlatency
3.in another shell bpftime start -s /bin/bash

Expected behavior
work properly.

Screenshots

Desktop (please complete the following information):

• OS: win11 WSL2 Ubuntu:2204

Best regards. :)

Is your feature request related to a problem? Please describe.

• Add syscall tracepoint support in attach ctx
• Add a test for syscall tracepoint
• Add benchmark for tracepoint overhead

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

Currently, if user choose using llvm-jit as ebpf runtime, injecting agent to bpftrace will fail.

Describe the bug

To Reproduce

make unit-test

it seems that the program is using local headers

Is your feature request related to a problem? Please describe.

We don't want to maintain different jit. The https://github.com/eunomia-bpf/bpftime/tree/master/vm/simple-jit was original ported from ubpf, there is no need to maintain it further.

We can use JIT directly from ubpf for resource constraints device where LLVM JIT is not suitable.

See https://github.com/eunomia-bpf/bpftime/actions/runs/6525355297/job/17717964845

Attach the following program:

// SPDX-License-Identifier: GPL-2.0
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
SEC("uretprobe/./example/simple_uretprobe_test/victim:simple_add")
int BPF_URETPROBE(simple_probe, long ret)
{
	bpf_printk("Ret=%ld\n", ret);

	return 0;
}

SEC("uretprobe/./example/simple_uretprobe_test/victim:simple_add")
int BPF_URETPROBE(simple_probe2, long ret)
{
	bpf_printk("Ret2=%ld\n", ret);

	return 0;
}

char LICENSE[] SEC("license") = "GPL";

victim:

#include <cstdint>
#include <fcntl.h>
#include <iostream>
#include <ostream>
#include <unistd.h>

extern "C" int64_t simple_add(int64_t a, int64_t b)
{
	return a + b;
}

int main()
{
	while (true) {
		for (int i = 1; i <= 10; i++) {
			for (int j = 1; j <= 10; j++) {
				int32_t ret = simple_add(i, j);
				std::cout << i << " + " << j << " = " << ret
					  << std::endl;
				usleep(1000 * 500);
			}
		}
	}
	return 0;
}

Will lead to the following output:

Ret2=1
Ret=2
1 + 1 = 2
Ret2=1
Ret=3
1 + 2 = 3
Ret2=1
Ret=4
1 + 3 = 4
Ret2=1
Ret=5
1 + 4 = 5

Where ret2 prints the first argument, not the return value, so it seems to be attached as uprobe

First of all: I'm really glad I found this repo, thank you for making uprobes faster!

I am working with maps that get updated by both uprobes and kprobes (essentially trying to do this).

Do your maps currently support reading/writing by both bpftime's uprobes as well as the usual kprobes?

Thanks!

Is your feature request related to a problem? Please describe.

Add verifier support from https://github.com/vbpf/ebpf-verifier/blob/main/src/crab_verifier.cpp#L238.

Use a flag to enable building verifier.

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

bpf_override_return helper can be used for replacing the replace/filter types. we needs to remove the deprecated code and fix the test cases.

Is your feature request related to a problem? Please describe.

Currently, our CI will test examples, however they are only tested against interpreter. We need to have tests when JIT is enable.

Describe the solution you'd like

Add a matrix for testing JIT in github actions CI.

Is your feature request related to a problem? Please describe.

Currently the daemon has few unit test because we have no so much time to add it.

Describe the solution you'd like

Add unit tests based on catch2 for daemon.

Describe alternatives you've considered

Provide usage examples

Additional context

Describe the bug

Failed to start example. Seems to be shared library path error.

To Reproduce

make release && make install && bpftime start ./example/malloc/victim
Expected behavior

Screenshots

$ bpftime start ./example/malloc/victim
[2023-11-07 06:32:03.859] [info] Entering bpftime agent
[2023-11-07 06:32:03.859] [info] Global shm constructed. shm_open_type 1 for bpftime_maps_shm
[2023-11-07 06:32:03.859] [info] Initializing agent..
[2023-11-07 06:32:03][info][422426] Executable path: /home/pdliyan/bpftime/example/malloc/victim
[2023-11-07 06:32:03][error][422426] Failed to find module base address for /lib/x86_64-linux-gnu/libc.so.6
[2023-11-07 06:32:03][info][422426] Attached 0 uprobe programs to function 0
Error: Exited with code: None

Desktop (please complete the following information):

• OS: Centos
• Version 8
  CentOS Linux release 8.4.2105

Additional context

My local libc.so.6 located in

$ whereis libc
libc: /usr/lib/libc.so /usr/lib64/libc.so

Something wrong with build configs?

Currently, text segment transformer uses libopcodes to disassemble asm bytes, but libopcodes haa an API break in recent versions. Replace that with frida-capstone to reduce redundant configuration.

Add eBPF AOT support for https://stackoverflow.com/questions/63091984/llvm-how-to-do-aot-compilation

As seen here, currently we have to build ebpf programs manually and put them in correct places to run tests. Avoid this redundant thing by building ebpf programs using CMake.

Reference:

• https://github.com/eunomia-bpf/bpftime-poc/blob/333bf35f2255a37abedfcc0c102d243f491a6b2e/documents/syscall-trace-with-ebpf/CMakeLists.txt#L63

Is your feature request related to a problem? Please describe.

Embed our vm in userspace functions and test the performance differents with uprobe.

Describe the solution you'd like

Describe alternatives you've considered

Provide usage examples

Additional context

Is your feature request related to a problem? Please describe.

No CI for benchmark examples

Describe the solution you'd like

add a shell script to test it, and run it in ci

Describe alternatives you've considered

Provide usage examples

Additional context

Due to the test on example/bash_readline, the ebpf program reads empty string from the return value. So there may be some issue on the handling of uretprobe.

boost::interprocess::mutex will introduce much more overhead for bpf helpers in update hash maps.

The latter supports shm, can be used for replace mutex.