Hello Piyush.
> I’m resending this email from my university account as my previous > message isn’t showing in the GCC mailing list archives. I’ve cc’d the > project mentors in case this email also fails to deliver. Apologies > for any duplicate notifications, and thank you for your understanding. > > ---------- Forwarded message --------- > From: Piyush Raj <piyushraj92...@gmail.com> > Date: Tue, 1 Apr 2025 at 01:46 > Subject: [GSoC] Tooling for running BPF GCC tests on a live kernel > To: <gcc@gcc.gnu.org> > > Hello, > I am an engineering student with experience in DevOps and SRE, > particularly in Linux automation, virtualization, and CI/CD > optimization. I do not have a formal Computer Science background, but > I learn as I go. I have built my own Linux From Scratch distro [1] and > am currently working on a container runtime in Bash [2]. I will > graduate in May 2025 and want to use my free time to work on > interesting projects. > > I am a beginner in C and eBPF, but have previously compiled a custom > kernel with eBPF support for use with Kata Containers [3]. To better > understand these eBPF and GCC architectures, I am currently studying > the Kernel BPF documentation [4] and David’s guide on GCC [5]. Sounds like a quite good background. Have you built GCC from sources? > I found "Tooling for Running BPF GCC Tests on a Live Kernel" > interesting and intend to apply for it in GSoC 2025. Thank you for your interest in working in this project in particular. It is an important task, and would greatly help the maintenance of the BPF port in the compiler. The BPF verifier is very picky and rejects a great deal of compiled valid C code. This basically means that any legit change in the compiler, such as a new optimization or even a bug fix, can potentially make it to generate non-verifiable code. Thus having a way to detect such regressions is very important. > From my research > on the current BPF development landscape: > - Only the kernel has tests against a live kernel [6], while Clang and > GCC perform compile-time tests. Correct. > - BPF CI [7] mainly tests kernel patches for regressions against the > latest GCC and LLVM snapshots, so it does not help much in catching > regressions in GCC itself. Also correct. As explained above, compiler changes can make the verifier unhappy. But so can new selftests added to the kernel that produce unveifiable code. > - Another project, little-vm-helper [8] by Cilium, also uses a > VM-based approach for BPF testing. I wasn't aware of that project. It may be a good reference, or maybe not, depending. > If there are other BPF testing projects that I should look into, > please let me know. At the past LSFMM conference someone suggested us to look at virtme-ng. Daniel Xu, a BPF kernel developer (who I added in CC) also recommended we look at https://github.com/danobi/vmtest, which he wrote. > I have a few questions and would appreciate any guidance from the > community > > 1. Are there specific BPF features or functionalities that cannot be > effectively tested in a VM environment due to virtualization? I don't think so. > 2. Should the new BPF test suite focus only on execution tests for > programs, or can we also include kernel selftests? I would focus on compiler oriented tests, exercising source constructions that have proven to generate unverifiable code. In contrast the kernel selftests focus on exercising all the supported BPF features in the kernel. The main goal of the testing shall be detecting verification regressions. > 3. The GDB simulator currently lacks full support for BPF features. > How do GCC developers typically debug the BPF programs generated by > GCC? We just look at the generated code when there are verification failures and try to determine, from the kernel verifier's output, what led to generating such code. > Would attaching a GDB debugger to the virtual machine[9] serve as an > effective debugging strategy? I don't think that is currently a possibility. AFAIK you can connect GDB to a running kernel in say qemu, and debug the kernel code. But I dont think you can debug BPF-jitted code. It is an intriguing possibility, but I think out of scope of this particular GSOC project. > Additionally, would automating this process provide significant value > to developers? I don't understand. Automating what exactly? > I'm drafting a detailed proposal and will share it soon. Thank you! :) > Thank you, > Piyush Raj > > [1] https://github.com/PiyushRaj927/LinuxFromScratch/ > [2] https://github.com/PiyushRaj927/bashpod/ > [3] https://gist.github.com/PiyushRaj927/5eb49595a82d9ca5313ae11e16593b71 > [4] https://www.kernel.org/doc/html/latest/bpf/index.html > [5] https://gcc-newbies-guide.readthedocs.io/en/latest/ > [6] https://github.com/torvalds/linux/tree/master/tools/testing/selftests/bpf > [7] https://gcc.gnu.org/pipermail/gcc/2025-January/245395.html > [8]https://github.com/cilium/little-vm-helper > [9] Debugging the BPF VM: https://youtu.be/1GSgyvn4N7E?t=7914
