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]? > > 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. 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/
