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

Reply via email to