[BUG] Compile modern_bpf error #1719
Comments
|
Thank you for reporting, can you provide more info?
|
Thank you for your attention!
|
|
Uhm ok looking at this compiler error it seems that even if your kernel supports the new if(bpf_core_type_exists(struct mm_rss_stat))
{
BPF_CORE_READ_INTO(&swap_entries, mm, rss_stat.count[MM_SWAPENTS].counter);
}
else
{
struct mm_struct___v6_2 *mm_v6_2 = (void *)mm;
BPF_CORE_READ_INTO(&swap_entries, mm_v6_2, rss_stat[MM_SWAPENTS].count);
}If you run these 2 commands on your machine, they should both return |
@Andreagit97 Certainly! It's true that I didn't enter the else but entered the first branch. I'm trying to clear it. This is why... |
|
I found that the reason is that the path to percpu_counter was not imported at compile time What should I do about it? |
|
Sorry, I didn't get it... if
I don't understand how this is related to the fact the the code finds a definition of |
|
@Andreagit97 |
Uhm i'm not sure this is an issue with /*
* Convenience macro to check that provided named type
* (struct/union/enum/typedef) exists in a target kernel.
* Returns:
* 1, if such type is present in target kernel's BTF;
* 0, if no matching type is found.
*/
#define bpf_core_type_exists(type) \
__builtin_preserve_type_info(*(typeof(type) *)0, BPF_TYPE_EXISTS)The best way to debug is to obtain the vmlinux.h of your kernel and see if this type is here or not. bpftool btf dump file /sys/kernel/btf/vmlinux format c | grep -q "mm_rss_stat" && echo "true" || echo "false"
bpftool btf dump file /sys/kernel/btf/vmlinux format c | grep -q "percpu_counter rss_stat" && echo "true" || echo "false" Can you just run this command and provide us with the bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h |
|
The root cause of the problem is the problem of the clang built-in function under the loongarch architecture |
of course，https://github.com/libbpf/libbpf-bootstrap/blob/master/vmlinux/loongarch/vmlinux_602.h |
|
@Andreagit97 If you would like my vmlinux.h from TCE-metal, I would be happy to provide it, please visit os:fedora Regarding this issue, I am consulting the relevant personnel in the llvm community responsible for the loongarch architecture. |
|
uhm ok i see... not sure this is the exact vmlinux of you machine but yes, in this vmlinux you provided there is no the |
Sir, I have provided the loongarch architecture vmlinux.h header file given by the libbpf official and the vmlinux.h generated by my machine respectively. Neither of these two header files from different sources mm_rss_stat structure |
|
use clang-14 error： |
|
ok, I read again the issue, and we are missing something... you are compiling this on your machine so what is happening is perfectly legit, the compiler is just saying that it cannot find a definition for |
Regarding this issue, if we wait for the built-in functions of clang to return to normal, it will take a long time. What are your suggestions? |
|
Uhm let me explain better what is happening here. On your local machine, to compile the modern ebpf probe, you have probably added another Now how can you solve this missing definition? #if defined(__TARGET_ARCH_loongarch)
struct mm_rss_stat {
atomic_long_t count[4];
};
#endifthis should solve this compilation issue, but there could be others since your vmlinux.h is generated on a recent loongarch machine... The best solution here would be to generate a vmlinux.h for loongarch in an older machine something with a kernel version <= 6.0.0, but not sure if you have a machine to do that |
mm_rss_stat structure does not exist when kernel version > 6.2.0, this definition may cause problems with project compilation. |
|
I wonder if we could change the criteria from mm_rss_stat to kernel version? to |
Unfortunately no, because these changes could be backported in older kernel versions (so before 6.2.0), many distros do similar things... so the best way to detect these changes is to check the struct existence... |
After debugging, it was found that there was no exception when running the bpf_core_type_exists () function. For higher kernels that do not have mm_rss_stat structures, the result returned by the loongarch platform is 0. |
|
@Andreagit97 |
|
ei @yzewei i think you have 2 possible solutions as explained here #1719 (comment);
If possible I would go for solution number 2, it would be easier for everyone since it should avoid ifdefs |
@Andreagit97 Compiling with vmlinux with a kernel smaller than 6.0 solved this problem, thank you for your guidance!! |
|
|
Ok now that you have this
Please note that you need to only take the |
Yes, I did it, I didn't encounter any other errors in the bpf part at present, but some data structures or data items do not exist due to kernel version problems. Under vmlinux.h, I added it in struct_flavors, let's see what problems will appear in the future |
|
@Andreagit97 Here's another question: |
|
ei @yzewei it seems like you have defined |
|
@Andreagit97 This problem is solved because system calls can be made under loongarch: sys_exit_execve |
|
But there is still a problem when making bpf, the following is the problem situation |
At present, the code needs to be sorted out and reviewed internally, so it will take some time to update the relevant code on the previous PR. Please understand, thank you very much！ |
|
@Andreagit97 The problem has been identified, because the branch instructions compiled by llc need to encode offsets greater than 2^16 instructions, which is beyond the limit of cpuv3 and requires the use of cpuv4, and then depends on the higher version of the kernel. Other methods are being communicated so that the lower version kernel can use the bpf module of libs |
|
oh, great catch! thank you for the update! |
Describe the bug
make drivers_test
The code files involved include :
modern_bpf/programs/tail_called/events/syscall_dispatched_events/execve.bpf.c modern_bpf/programs/tail_called/events/syscall_dispatched_events/execveat.bpf.c modern_bpf/helpers/extract/extract_from_kernel.h
How to reproduce it
First judge the kernel version, and then execute the corresponding operation. like this:
instead of
Expected behaviour
Screenshots
Environment
Additional context
Tasks
Tasks
The text was updated successfully, but these errors were encountered: