riscv: initial ebpf support #4085

xmzzz · 2022-07-03T16:21:21Z

In order to fix the issue #4081 , some basic support for RISC-V64 has been added. With this patch, running examples/hello_world.py can get the expected result.

However, BCC tool using bpf_probe_read() helper, which will report an error on RISC-V64 because the ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE config option in kernel is not set. This will be resolved by updating the BCC tools and BCC itself with the appropriate bpf_probe_read_{kernel,user}[_str()] helpers.

This PR currently only supports RISCV64.

Signed-off-by: Mingzheng Xing mingzheng.xing@gmail.com
Co-authored-by: Yixun Lan dlan@gentoo.org

src/cc/export/helpers.h

dlan17

no need to mention the kernel patch here anymore, which won't be accepted by kernel upstream,
besides it's a different problem that we need to fix

you really need to add slightly more messages to explain what's the PR aim for, and what's the status?

xmzzz · 2022-07-07T10:25:34Z

no need to mention the kernel patch here anymore, which won't be accepted by kernel upstream, besides it's a different problem that we need to fix

you really need to add slightly more messages to explain what's the PR aim for, and what's the status?

Thank you for your suggestion, @dlan17 , has been modified accordingly. Kindly verify.

Add basic support for RISC-V64. Fix the issue iovisor#4081 . With this patch, running examples/hello_world.py can get the expected result. Signed-off-by: Mingzheng Xing <mingzheng.xing@gmail.com> Co-authored-by: Yixun Lan <dlan@gentoo.org>

euspectre · 2022-07-08T14:25:21Z

Thanks for looking into this!

I have a question concerning bpf_probe_read(). You wrote that

BCC tool using bpf_probe_read() helper, which will report an error on RISC-V64 because the ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE config option in kernel is not set. This will be resolved by updating the BCC tools and BCC itself with the appropriate bpf_probe_read_{kernel,user}[_str()] helpers.

execsnoop tool seems to use only bpf_probe_read_user() directly, rather than bpf_probe_read(). However, when I tried to launch it, it failed as follows:

root@riscv64-test: # /usr/share/bcc/tools/execsnoop

bpf: Failed to load program: Invalid argument
0: (bf) r6 = r1
1: (79) r8 = *(u64 *)(r6 +88)
[...]
56: (85) call bpf_probe_read#4
unknown func bpf_probe_read#4

processed 57 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1

Traceback (most recent call last):
  File "/usr/share/bcc/tools/execsnoop", line 229, in <module>
    b.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")
  File "/usr/lib/python3/dist-packages/bcc/__init__.py", line 837, in attach_kprobe
    fn = self.load_func(fn_name, BPF.KPROBE)
  File "/usr/lib/python3/dist-packages/bcc/__init__.py", line 522, in load_func
    raise Exception("Failed to load BPF program %s: %s" %
Exception: Failed to load BPF program b'syscall__execve': Invalid argument

I observed this in a VM (riscv64) with Ubuntu 22.04 and kernel 5.15.0-1014-generic. bcc was built from the sources with your patch included.

So, I guess, the BPF program still tries to use bpf_probe_read() rather than bpf_probe_read_user() for some reason. Some fallback in cc/frontends/clang/b_frontend_action.cc, perhaps?

I'll re-check this on a clean build of bcc with your patch, just in case I messed something up locally, but still.

euspectre · 2022-07-08T14:29:04Z

@dlan17 By the way, how did you enable debug like in #4081 (comment)?

In some of my experiments with this fix, I saw a warning when trying to load certain BPF programs:
WARNING: This target JIT is not designed for the host you are running. If bad things happen, please choose a different -march switch. Looks suspicious, but I need to check the exact compiler options.

xmzzz · 2022-07-08T14:50:54Z

Thanks for looking into this!

Thanks for your comment. @euspectre
I also found this error in testing and need to find out the cause further.

This PR solves the basic support problem of BCC on RISCV64. It seems that we should open a new issue.

dlan17 · 2022-07-08T14:56:03Z

Thanks for looking into this!

I have a question concerning bpf_probe_read(). You wrote that

BCC tool using bpf_probe_read() helper, which will report an error on RISC-V64 because the ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE config option in kernel is not set. This will be resolved by updating the BCC tools and BCC itself with the appropriate bpf_probe_read_{kernel,user}[_str()] helpers.

execsnoop tool seems to use only bpf_probe_read_user() directly, rather than bpf_probe_read(). However, when I tried to launch it, it failed as follows:
root@riscv64-test: # /usr/share/bcc/tools/execsnoop

bpf: Failed to load program: Invalid argument
0: (bf) r6 = r1
1: (79) r8 = *(u64 *)(r6 +88)
[...]
56: (85) call bpf_probe_read#4
unknown func bpf_probe_read#4

the error is expected, but shouldn't block this PR

processed 57 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1

Traceback (most recent call last):
File "/usr/share/bcc/tools/execsnoop", line 229, in
b.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")
File "/usr/lib/python3/dist-packages/bcc/init.py", line 837, in attach_kprobe
fn = self.load_func(fn_name, BPF.KPROBE)
File "/usr/lib/python3/dist-packages/bcc/init.py", line 522, in load_func
raise Exception("Failed to load BPF program %s: %s" %
Exception: Failed to load BPF program b'syscall__execve': Invalid argument
I observed this in a VM (riscv64) with Ubuntu 22.04 and kernel 5.15.0-1014-generic. bcc was built from the sources with your patch included.

So, I guess, the BPF program still tries to use bpf_probe_read() rather than bpf_probe_read_user() for some reason. Some fallback in cc/frontends/clang/b_frontend_action.cc, perhaps?

Yes, it still use bpf_probe_read(), you can enable debug, and dump the bpf code

I'll re-check this on a clean build of bcc with your patch, just in case I messed something up locally, but still.

there is an attempt to try to resolve in kernel side but people don't like it, see [0]

[0] https://lore.kernel.org/bpf/YsUy8jBpt11zoc5E@infradead.org/T/

dlan17 · 2022-07-08T14:59:37Z

@dlan17 By the way, how did you enable debug like in #4081 (comment)?

add debug in python code, for example you can edit /usr/lib/python-exec/python3.9/execsnoop,
change BPF(text=bpf_text) to BPF(text=bpf_text, debug=0xff)

In some of my experiments with this fix, I saw a warning when trying to load certain BPF programs: WARNING: This target JIT is not designed for the host you are running. If bad things happen, please choose a different -march switch. Looks suspicious, but I need to check the exact compiler options.

the error come from llvm/clang, I'm no llvm expert, and haven't really looked into it..

euspectre · 2022-07-08T15:29:43Z

@xmzzz @dlan17 Thanks for the info.

Yes, the issue with bpf_probe_read() should not block this PR.

dlan17 · 2022-07-08T15:43:31Z

Thanks for looking into this!

I have a question concerning bpf_probe_read(). You wrote that

BCC tool using bpf_probe_read() helper, which will report an error on RISC-V64 because the ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE config option in kernel is not set. This will be resolved by updating the BCC tools and BCC itself with the appropriate bpf_probe_read_{kernel,user}[_str()] helpers.

execsnoop tool seems to use only bpf_probe_read_user() directly, rather than bpf_probe_read(). However, when I tried to launch it, it failed as follows:
root@riscv64-test: # /usr/share/bcc/tools/execsnoop

bpf: Failed to load program: Invalid argument
0: (bf) r6 = r1
1: (79) r8 = *(u64 *)(r6 +88)
[...]
56: (85) call bpf_probe_read#4
unknown func bpf_probe_read#4

just trace this down, it's problem in file : execsnoop

int do_ret_sys_execve(struct pt_regs *ctx)
{
..
data.ppid = task->real_parent->tgid;
..
}
expand to
{
..
data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)&({ typeof(struct task_struct *) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)&task->real_parent); _val; })->tgid); _val; });
..
}

any idea where this expansion come from? and if we can fix it, then will solve the problem..

euspectre · 2022-07-08T16:47:54Z

any idea where this expansion come from? and if we can fix it, then will solve the problem..

Looks like it is here:
(src/cc/frontends/clang/b_frontend_action.cc)

ProbeVisitor::ProbeVisitor(ASTContext &C, Rewriter &rewriter,
                           set<Decl *> &m, bool track_helpers) :
  C(C), rewriter_(rewriter), m_(m), ctx_(nullptr), track_helpers_(track_helpers),
  addrof_stmt_(nullptr), is_addrof_(false) {
  const char **calling_conv_regs = get_call_conv();
  has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x;
}

has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x; looks suspicious.

has_overlap_kuaddr_ is later used to delect bpf_probe_read() VS bpf_probe_read_kernel().

euspectre · 2022-07-08T16:53:39Z

How about smth like this:

diff --git a/src/cc/frontends/clang/b_frontend_action.cc b/src/cc/frontends/clang/b_frontend_action.cc
index 9b2853a9..f3ab0bf0 100644
--- a/src/cc/frontends/clang/b_frontend_action.cc
+++ b/src/cc/frontends/clang/b_frontend_action.cc
@@ -330,7 +330,8 @@ ProbeVisitor::ProbeVisitor(ASTContext &C, Rewriter &rewriter,
   C(C), rewriter_(rewriter), m_(m), ctx_(nullptr), track_helpers_(track_helpers),
   addrof_stmt_(nullptr), is_addrof_(false) {
   const char **calling_conv_regs = get_call_conv();
-  has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x;
+  has_overlap_kuaddr_ = (calling_conv_regs == calling_conv_regs_s390x ||
+                         calling_conv_regs == calling_conv_regs_riscv64);
 }
 
 bool ProbeVisitor::assignsExtPtr(Expr *E, int *nbDerefs) {

Not tested yet.

dlan17 · 2022-07-09T00:48:49Z

How about smth like this:

diff --git a/src/cc/frontends/clang/b_frontend_action.cc b/src/cc/frontends/clang/b_frontend_action.cc
index 9b2853a9..f3ab0bf0 100644
--- a/src/cc/frontends/clang/b_frontend_action.cc
+++ b/src/cc/frontends/clang/b_frontend_action.cc
@@ -330,7 +330,8 @@ ProbeVisitor::ProbeVisitor(ASTContext &C, Rewriter &rewriter,
   C(C), rewriter_(rewriter), m_(m), ctx_(nullptr), track_helpers_(track_helpers),
   addrof_stmt_(nullptr), is_addrof_(false) {
   const char **calling_conv_regs = get_call_conv();
-  has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x;
+  has_overlap_kuaddr_ = (calling_conv_regs == calling_conv_regs_s390x ||
+                         calling_conv_regs == calling_conv_regs_riscv64);
 }
 
 bool ProbeVisitor::assignsExtPtr(Expr *E, int *nbDerefs) {

Not tested yet.

hey, I've tested, it actually works (does fix the bpf_probe_read() problem), and there are two code lines which need to be fixed.

but the variable 'has_overlap_kuaddr_' here is confusing, as my knowledge, the virtual address space in riscv64 does not have overlap address space, see kernel doc [0], and please correct me if I'm wrong here?

there is already the logic to probe whether the system support separate k/u address, so how about we reusing it?

static std::string check_bpf_probe_read_kernel(void) {
bool is_probe_read_kernel;
is_probe_read_kernel = bcc_symcache_resolve_name(resolver, nullptr,
"bpf_probe_read_kernel", &addr) >= 0 ? true: false;
..
}

so the logic I'd propose:

ProbeVisitor::ProbeVisitor(ASTContext &C, Rewriter &rewriter,
{
const char **calling_conv_regs = get_call_conv();
has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x;
is_probe_read_kernel = bcc_symcache_resolve_name(resolver, nullptr,
"bpf_probe_read_kernel", &addr) >= 0 ? true: false;

has_probe_read_separated = has_overlap_kuaddr_ || is_probe_read_kernel;
}

[0] https://www.kernel.org/doc/html/latest/riscv/vm-layout.html

dlan17 · 2022-07-09T02:33:28Z

How about smth like this:

diff --git a/src/cc/frontends/clang/b_frontend_action.cc b/src/cc/frontends/clang/b_frontend_action.cc
index 9b2853a9..f3ab0bf0 100644
--- a/src/cc/frontends/clang/b_frontend_action.cc
+++ b/src/cc/frontends/clang/b_frontend_action.cc
@@ -330,7 +330,8 @@ ProbeVisitor::ProbeVisitor(ASTContext &C, Rewriter &rewriter,
   C(C), rewriter_(rewriter), m_(m), ctx_(nullptr), track_helpers_(track_helpers),
   addrof_stmt_(nullptr), is_addrof_(false) {
   const char **calling_conv_regs = get_call_conv();
-  has_overlap_kuaddr_ = calling_conv_regs == calling_conv_regs_s390x;
+  has_overlap_kuaddr_ = (calling_conv_regs == calling_conv_regs_s390x ||
+                         calling_conv_regs == calling_conv_regs_riscv64);
 }
 
 bool ProbeVisitor::assignsExtPtr(Expr *E, int *nbDerefs) {

Not tested yet.

@euspectre would you like to pursue the bpf_probe_read_{kernel/user}() implementation in bcc? and send a PR here? I would more than happy to help testing/reviewing the changes

thanks

euspectre · 2022-07-09T07:42:24Z

@xmzzz

but the variable 'has_overlap_kuaddr_' here is confusing

Indeed.

@dlan17

would you like to pursue the bpf_probe_read_{kernel/user}() implementation in bcc? and send a PR here? I would more than happy to help testing/reviewing the changes

Yes, I'll try it in a separate PR. However, I am still new to bcc and need some time to better understand the code.

I read the discussion you mentioned (https://lore.kernel.org/bpf/YsUzX2IeNb%2Fu9VmN@infradead.org/) and, it seems, they suggest using bpf_probe_read_(user|kernel) unconditionally if they are available, and only try bpf_probe_read() as a fallback.

This way, if I understand it correctly, all checks for overlapping memory areas could be removed along with the confusion they cause. Instead, we could check if bpf_probe_read_(user|kernel)[str] are available in the kernel. This should be possible to implement.

alexfanqi · 2022-07-09T09:44:49Z

the error come from llvm/clang, I'm no llvm expert, and haven't really looked into it.

I tried to examine into it. This is a mcjit riscv support issue. ExecutionEngine and EngineBuilder is the old mcjit api, which bcc seems to be using. It has no problem supporting jit into bpf code, but doesn't support jit into riscv native code and will never do so because it is being superceded by orc jit. A grep into llvm/lib/ExexutionEngine shows this warning come from https://github.com/llvm/llvm-project/blob/355532a1499aa9b13a89fb5b5caaba2344d57cd7/llvm/lib/ExecutionEngine/ExecutionEngine.cpp#L529. This confirms riscv has no mcjit support. So in

bcc/src/cc/bpf_module.h

Line 162 in 13b5563

std::unique_ptr<llvm::ExecutionEngine> engine_;

, the first ExecutionEngine instance engine_ jitting into bpf works okay on riscv, but the second rw_engine_ jitting to native riscv code will not work.

I guess disabling ENABLE_LLVM_NATIVECODEGEN should work around this warning for now. In a long run if debug is needed, rw_engine may need to be migrated to orcji v2, which fully support riscv already.

yonghong-song · 2022-07-11T04:56:24Z

@chenhengqi and @dlan17 thanks for code reviews for this pull request and #4088. I don't have an environment for riscv, so I will not merge the patch unless one of you gave an approval. It is not necessary to have all support in one patch. But hopefully the first patch can provide some basic support at the least.

dlan17 · 2022-07-11T06:05:40Z

@chenhengqi and @dlan17 thanks for code reviews for this pull request and #4088. I don't have an environment for riscv, so I will not merge the patch unless one of you gave an approval. It is not necessary to have all support in one patch. But hopefully the first patch can provide some basic support at the least.

@yonghong-song Yes, this PR provide some basic support for riscv64 platform. You can add a "Tested-by: Yixun Lan dlan@gentoo.org" if that work for you.

The hardware I'm testing is a sifive unmatched board which is a riscv64 (rv64gc) platform,
and it's a Gentoo Linux OS I'm running, which has kernel 5.18.7 and llvm/clang-14.0.6.

With this PR, examples/hello_world.py from bcc is just able to run.
`# ./examples/hello_world.py

b' tmux: server-2642 [001] d...1 718598.584658: bpf_trace_printk: Hello, World!'
b''
b' tmux: server-2642 [001] d...1 718598.597710: bpf_trace_printk: Hello, World!'
`

If we apply extra patch either from [0] or [1] to fix the bpf_probe_read_{kernel,user}() issue, then we are able to run more bpf tools: like execsnoop, runqlen, and more..

[0] https://lore.kernel.org/20220703130924.57240-1-dlan@gentoo.org
[1] #4085 (comment)

thanks

euspectre · 2022-07-15T17:45:31Z

@euspectre would you like to pursue the bpf_probe_read_{kernel/user}() implementation in bcc? and send a PR here? I would more than happy to help testing/reviewing the changes

@dlan17 I have prepared the fix for bpf_probe_read() issue in a separate PR: #4109.

yonghong-song · 2022-08-04T07:12:06Z

@xmzzz @dlan17 @chenhengqi With latest llvm-project release/15.x branch or main branch (llvm16), and the following bcc cmake

cmake3 .. \
    -DPYTHON_CMD=python3.6 \
    -DCMAKE_INSTALL_PREFIX=/usr

I got the following compilation error:

[100%] Building CXX object tests/cc/CMakeFiles/test_libbcc.dir/test_shared_table.cc.o
/home/yhs/work/llvm-project/llvm/build/install/lib/libclangSema.a(SemaRISCVVectorLookup.cpp.o): In func
tion `(anonymous namespace)::RISCVIntrinsicManagerImpl::InitIntrinsicList()':
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x14
b): undefined reference to `clang::RISCV::RVVIntrinsic::computeBuiltinTypes(llvm::ArrayRef<clang::RISCV
::PrototypeDescriptor>, bool, bool, bool, unsigned int)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x18
2): undefined reference to `clang::RISCV::RVVIntrinsic::computeBuiltinTypes(llvm::ArrayRef<clang::RISCV
::PrototypeDescriptor>, bool, bool, bool, unsigned int)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x8d
2): undefined reference to `clang::RISCV::RVVType::computeTypes(clang::RISCV::BasicType, int, unsigned 
int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x90
0): undefined reference to `clang::RISCV::RVVIntrinsic::getSuffixStr[abi:cxx11](clang::RISCV::BasicType
, int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x92
3): undefined reference to `clang::RISCV::RVVIntrinsic::getSuffixStr[abi:cxx11](clang::RISCV::BasicType
, int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x11
e7): undefined reference to `clang::RISCV::RVVType::computeTypes(clang::RISCV::BasicType, int, unsigned
 int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
collect2: error: ld returned 1 exit status
make[2]: *** [examples/cpp/CMakeFiles/CGroupTest.dir/build.make:177: examples/cpp/CGroupTest] Error 1
make[1]: *** [CMakeFiles/Makefile2:1110: examples/cpp/CMakeFiles/CGroupTest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
...
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x900): undefined reference to `clang::RISCV::RVVIntrinsic::getSuffixStr[abi:cxx11](clang::RISCV::BasicType, int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x923): undefined reference to `clang::RISCV::RVVIntrinsic::getSuffixStr[abi:cxx11](clang::RISCV::BasicType, int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
SemaRISCVVectorLookup.cpp:(.text._ZN12_GLOBAL__N_125RISCVIntrinsicManagerImpl17InitIntrinsicListEv+0x11e7): undefined reference to `clang::RISCV::RVVType::computeTypes(clang::RISCV::BasicType, int, unsigned int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
collect2: error: ld returned 1 exit status
make[2]: *** [tests/cc/CMakeFiles/test_static.dir/build.make:177: tests/cc/test_static] Error 1
make[1]: *** [CMakeFiles/Makefile2:1472: tests/cc/CMakeFiles/test_static.dir/all] Error 2
[100%] Linking CXX executable test_libbcc
/home/yhs/work/bcc/build/src/cc/libbcc.so: undefined reference to `clang::RISCV::RVVType::computeTypes(clang::RISCV::BasicType, int, unsigned int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
/home/yhs/work/bcc/build/src/cc/libbcc.so: undefined reference to `clang::RISCV::RVVIntrinsic::computeBuiltinTypes(llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>, bool, bool, bool, unsigned int)'
/home/yhs/work/bcc/build/src/cc/libbcc.so: undefined reference to `clang::RISCV::RVVIntrinsic::getSuffixStr[abi:cxx11](clang::RISCV::BasicType, int, llvm::ArrayRef<clang::RISCV::PrototypeDescriptor>)'
collect2: error: ld returned 1 exit status
make[2]: *** [tests/cc/CMakeFiles/test_libbcc.dir/build.make:371: tests/cc/test_libbcc] Error 1
make[1]: *** [CMakeFiles/Makefile2:1499: tests/cc/CMakeFiles/test_libbcc.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

I haven't done any investigation yet. Could any of you help take a look? Thanks!

dlan17 · 2022-08-04T07:39:34Z

clang::RISCV::RVVType::computeTypes is changed, see https://reviews.llvm.org/D126742

not sure why you got this error, but it sounds bcc is trying to link old llvm lib?

btw, I'm here using the released version of llvm-14.0.6

yonghong-song · 2022-08-04T17:43:15Z

@dlan17 I did some bisecting, the following llvm (llvm15 release branch or llvm16) triggered the failure:
https://reviews.llvm.org/D111617

commit 7a5cb15ea6facd82756adafae76d60f36a0b60fd (m6)
Author: Kito Cheng <kito.cheng@sifive.com>
Date:   Wed Jul 13 15:52:17 2022 +0800

    [RISCV] Lazily add RVV C intrinsics.
    
    Leverage the method OpenCL uses that adds C intrinsics when the lookup
    failed. There is no need to define C intrinsics in the header file any
    more. It could help to avoid the large header file to speed up the
    compilation of RVV source code. Besides that, only the C intrinsics used
    by the users will be added into the declaration table.
...

The patch is merged on July 13, 2022.

I think bcc/cmake/clang_libs.cmake needs updated with additional clang libs. Please help take a look.

yonghong-song · 2022-08-10T04:46:20Z

Okay, the patch #4154 should fix the problem.

Add basic support for RISC-V64. Fix the issue iovisor#4081 . With this patch, running examples/hello_world.py can get the expected result. Tested-by: Yixun Lan dlan@gentoo.org Signed-off-by: Mingzheng Xing <mingzheng.xing@gmail.com> Co-authored-by: Yixun Lan <dlan@gentoo.org>

xmzzz requested review from drzaeus77, yonghong-song, 4ast and davemarchevsky as code owners July 3, 2022 16:21

chenhengqi reviewed Jul 4, 2022

View reviewed changes

src/cc/export/helpers.h Outdated Show resolved Hide resolved

src/cc/export/helpers.h Outdated Show resolved Hide resolved

xmzzz force-pushed the riscv branch from 5313a9d to 79f851f Compare July 6, 2022 14:33

dlan17 reviewed Jul 6, 2022

View reviewed changes

xmzzz force-pushed the riscv branch from 79f851f to ef7f052 Compare July 7, 2022 10:05

xmzzz requested review from goldshtn and brendangregg as code owners July 7, 2022 10:05

riscv: initial ebpf support

1c37144

Add basic support for RISC-V64. Fix the issue iovisor#4081 . With this patch, running examples/hello_world.py can get the expected result. Signed-off-by: Mingzheng Xing <mingzheng.xing@gmail.com> Co-authored-by: Yixun Lan <dlan@gentoo.org>

xmzzz force-pushed the riscv branch from ef7f052 to 1c37144 Compare July 7, 2022 10:50

yonghong-song merged commit ca03af7 into iovisor:master Jul 11, 2022

xmzzz mentioned this pull request Jul 16, 2022

RISC-V: cachestat tool fails to run: "no member named 'pc' in 'struct pt_regs'" #4110

Closed

This was referenced Jul 19, 2022

bcc: Use bpf_probe_read_{kernel|user} functions if they are available #4109

Closed

riscv: using bpf_probe_read_{kernel|user} on riscv64 #4118

Merged

xmzzz deleted the riscv branch July 29, 2022 07:24

chenhengqi mentioned this pull request Mar 1, 2023

Some Debian archs are not supported yet (armv7l, i686, mips, sparc64). #4501

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

riscv: initial ebpf support #4085

riscv: initial ebpf support #4085

xmzzz commented Jul 3, 2022 •

edited

dlan17 left a comment

xmzzz commented Jul 7, 2022

euspectre commented Jul 8, 2022

euspectre commented Jul 8, 2022

xmzzz commented Jul 8, 2022

dlan17 commented Jul 8, 2022

dlan17 commented Jul 8, 2022

euspectre commented Jul 8, 2022

dlan17 commented Jul 8, 2022

euspectre commented Jul 8, 2022 •

edited

euspectre commented Jul 8, 2022

dlan17 commented Jul 9, 2022

dlan17 commented Jul 9, 2022

euspectre commented Jul 9, 2022 •

edited

alexfanqi commented Jul 9, 2022 •

edited

yonghong-song commented Jul 11, 2022

dlan17 commented Jul 11, 2022

euspectre commented Jul 15, 2022

yonghong-song commented Aug 4, 2022

dlan17 commented Aug 4, 2022

yonghong-song commented Aug 4, 2022

yonghong-song commented Aug 10, 2022

riscv: initial ebpf support #4085

riscv: initial ebpf support #4085

Conversation

xmzzz commented Jul 3, 2022 • edited

dlan17 left a comment

Choose a reason for hiding this comment

xmzzz commented Jul 7, 2022

euspectre commented Jul 8, 2022

euspectre commented Jul 8, 2022

xmzzz commented Jul 8, 2022

dlan17 commented Jul 8, 2022

dlan17 commented Jul 8, 2022

euspectre commented Jul 8, 2022

dlan17 commented Jul 8, 2022

euspectre commented Jul 8, 2022 • edited

euspectre commented Jul 8, 2022

dlan17 commented Jul 9, 2022

dlan17 commented Jul 9, 2022

euspectre commented Jul 9, 2022 • edited

alexfanqi commented Jul 9, 2022 • edited

yonghong-song commented Jul 11, 2022

dlan17 commented Jul 11, 2022

euspectre commented Jul 15, 2022

yonghong-song commented Aug 4, 2022

dlan17 commented Aug 4, 2022

yonghong-song commented Aug 4, 2022

yonghong-song commented Aug 10, 2022

xmzzz commented Jul 3, 2022 •

edited

euspectre commented Jul 8, 2022 •

edited

euspectre commented Jul 9, 2022 •

edited

alexfanqi commented Jul 9, 2022 •

edited