Hello Apologies for sending my draft proposal so close to the deadline. You can find it here: https://docs.google.com/document/d/1UL-mGDWyfEjne3f6uEZOI5KG4s9XTP53QZ_LJjoqn-s/edit?usp=sharing
Please share any comments or suggestions you might have. If any section needs more clarity, do let me know, I'd be happy to revise it. I’ll update the PDF on the GSoC portal accordingly. Thanks! On Thu, 3 Apr 2025 at 19:07, Jose E. Marchesi <jose.march...@oracle.com> wrote: > 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). Sure, I’ve already planned time in the schedule for compiling those and adding them to the testsuite. > 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 :) Thanks for the detailed explanation! I was mainly curious about the current state of debugging tools and techniques for eBPF, especially when dealing with large or complex programs. I’ll definitely try to explore this further once my semester wraps up in May :) Best regards, Piyush