> On Tue, Apr 1, 2025 at 8:07 PM Jose E. Marchesi > <jose.march...@oracle.com> wrote: >> >> Hello Piyush. > Hello Jose, > >> Sounds like a quite good background. > Thank you! > >> Have you built GCC from sources? > Yes, I have. I built GCC while working on LFS and recently rebuilt it, > running the test suite while going through the "Before you apply" > section on the GSoC page. >> > 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. > Thanks! I’ll check it out. > >> Daniel Xu, a BPF kernel developer (who I added in CC) also recommended >> we look at https://github.com/danobi/vmtest, which he wrote. > > Yes, I came across Daniel’s work during my research [1][2]. I was > planning to use vmtest for running the VM like in BPF CI. > >> > 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. > > Understood! Are there any existing collections of such source files > that have caused verification failures? Are they tracked in Bugzilla > beyond these issues [3]?
We get reports occassionally and normally we open bugzillas for them, but not always. We can compile a list of recent fixes for particular verification failure so a set of initial tests can be written during the GSOC project. Going forward, once the run-time testsuite is in place, each fix shall be accompanied with the corresponding new test(s). >> > 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 meant automating the process of opening a debugger with breakpoints > when the kernel starts executing eBPF code. But as you mentioned > earlier, this may not be feasible or would require more work than fits > within the current GSoC scope. BPF programs are hooked into the kernel via several mechanisms: kprobes, etc. There may be a way to locate these points using GDB. However, note that the BPF code gets JITted into whatever native native instructions of the host architecture. Having a debugger relating the JITted native instructions to the corresponding source locations would require the JITter to somehow translate the debug info as well I guess... an interesting perspective but definitely out of scope of this project :) > > I also found some ongoing work related to BPF debugging in the kernel > [4]. > > Thank you, > Piyush > > [1] http://oldvger.kernel.org/bpfconf2024_material/BPF-CI.pdf > [2] https://www.youtube.com/watch?v=NT-325hgXjY > [3] > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&order=Importance&query_format=advanced&short_desc=bpf&short_desc_type=allwordssubstr > [4] > https://lore.kernel.org/lkml/am6pr03mb50804a5bf211e94a5df8f66699...@am6pr03mb5080.eurprd03.prod.outlook.com/
