一、报错背景
libbpf: failed to open '/sys/kernel/tracing/events/syscalls/sys_enter_write/id': No such file or directory
libbpf: failed to determine tracepoint 'syscalls/sys_enter_write' perf event ID: No such file or directory
libbpf: prog 'handle_tp': failed to create tracepoint 'syscalls/sys_enter_write' perf event: No such file or directory
libbpf: prog 'handle_tp': failed to auto-attach: -2
Failed to attach BPF skeleton
二、分析思路
由于系统找不到/sys/kernel/tracing 和 /sys/kernel/debug路径,检查了qemu模拟的aarch确实没有看到该debug文件系统的存在,一开始以为是内核编译的时候模块配置的问题,仔细认真检查,尝试开启DEBUG_FS相关的各种模块配置之后,还是同样的报错。
所以尝试直接手动挂载debug_fs文件系统,正确的路径确实是:
bash
mount -t debugfs none /sys/kernel/debug
完成路径挂载之后,看到/sys/kernel/debug目录下出现了文件,但是执行命令仍然报错。
仔细检查路径之后,看到报错的其实是在/sys/kernel/tracing/路径之下,所以就尝试将debugfs挂载到了上一级目录,执行竟然成功了。但是真相肯定不是止步于此。
bash
mount -t debugfs none /sys/kernel
为了搞清楚在libbfp里为什么是挂载到/sys/kernel路径,而不是/sys/kernel/debug路径,单步调试libbpf源码,找到如下内容:
系统会根据faccessat去检查debugfs路径是否存在,起初以为手动挂载上debugfs之后应该就会正常,设置启动自动挂载,重启系统,检查/sys/kernel/debug文件路径是否存在,发现就算启动之后就存在,执行仍然失败。
bash
echo "none /sys/kernel/debug debugfs defaults 0 0" | te
e -a /etc/fstab
在源码中增加打印,查找执行失败的原因,报错Function not implemented。
cpp
static bool use_debugfs(void)
{
static int has_debugfs = -1;
if (has_debugfs < 0) {
has_debugfs = faccessat(AT_FDCWD, DEBUGFS, F_OK, AT_EACCESS) == 0;
perror("faccessat");
}
return has_debugfs == 1;
}
对于这个报错AI提供了两个方向:
内核本文使用的是5.4.123,不存在是内核的原因;其次是检查系统的glibc版本,确实只是2.38。尝试使用buildroot更换更新的libc版本,但是发现这个已经比较新,也没有能手动指定glibc版本的地方。
是否是QEMU环境的问题也无从得知,如果有大佬清楚,麻烦留言帮忙解答。
三、解决方案
既然faccessat限制使用,那就换用类似的替代函数。access函数来判定文件目录是否存在,编译之后,执行成功。