LPC BoF - Linux Kernel Debugging & Drgn

LPC BoF - Linux Kernel Debugging & Drgn

[Stephen Brennan]

Hello everyone!

For those attending Plumbers in-person or virtually, we will be having a
BoF session where we can get together and discuss debuggers. I'll have
some interactive demos which should be easy enough in case folks want a
quick and easy way to get started playing with Drgn, but really it's
just going to be an attendee-driven discussion. So please show up, bring
questions, ideas, or things to share of your own!

The BoF is scheduled for 3:45PM CET on Thursday (Sept 19), which is:

9:45 AM US Eastern
6:45 AM US Pacific

This has the nice benefit of avoiding the Toolchain track (Wed) and the
Perf/Tracing MC (Fri), but it does intersect with some of the BPF MC,
somewhat unavoidably.

But these times could be subject to change, please check the below
listing on the LPC schedule in case of any changes.

https://lpc.events/event/18/contributions/1982/

Looking forward to seeing everyone in Vienna or online!

Thanks,
Stephen

Re: LPC BoF - Linux Kernel Debugging & Drgn

[Stephen Brennan]

Hello all,

This will be happening in 20 minutes. Remote users can login at
https://meet.lpc.events, select the "Birds of a Feather" room, and join.
You can also join the matrix room for the BOF room here:
https://matrix.to/#/#bofs:lpc.events

Thanks,
Stephen

Stephen Brennan <stephen.s.brennan@oracle.com> writes:
> Hello everyone!
>
> For those attending Plumbers in-person or virtually, we will be having a
> BoF session where we can get together and discuss debuggers. I'll have
> some interactive demos which should be easy enough in case folks want a
> quick and easy way to get started playing with Drgn, but really it's
> just going to be an attendee-driven discussion. So please show up, bring
> questions, ideas, or things to share of your own!
>
> The BoF is scheduled for 3:45PM CET on Thursday (Sept 19), which is:
>
> 9:45 AM US Eastern
> 6:45 AM US Pacific
>
> This has the nice benefit of avoiding the Toolchain track (Wed) and the
> Perf/Tracing MC (Fri), but it does intersect with some of the BPF MC,
> somewhat unavoidably.
>
> But these times could be subject to change, please check the below
> listing on the LPC schedule in case of any changes.
>
> https://lpc.events/event/18/contributions/1982/
>
> Looking forward to seeing everyone in Vienna or online!
>
> Thanks,
> Stephen

Re: LPC BoF - Linux Kernel Debugging & Drgn

[Stephen Brennan]

Hi everyone,

Thank you for joining the BoF, by all indication it was quite
successful, despite my apparent attempts at sabotage by changing the
room last minute. I took notes as we went (though couldn't cover
everything), which I've included below.

Thanks,
Stephen

---

​* Drgn within IPython notebooks!  Useful to help people follow & understand debugging sessions. -Shung-Hsi Yu

* What is the criteria for "contrib/" vs "helpers/"? - Sweet Tea Dorminy.
  -> Unit test cases!
  -> Converting contrib/ to helpers/ is a valid and good on-ramp to drgn development.
  -> Though, not all contrib scripts are expected to make it in.
  -> There is also a "tools/" directory which is actually tested & supported.

* Is there a "rosetta stone" comparison between operations in drgn and crash?
  -> Not currently!
  -> I (Stephen) have some which I could move out of an internal wiki into Drgn's wiki.

* Drgn "commands" vs Crash commands. Drgn does not yet have a command structure, it's been discussed.

* What is the status of drgn without debuginfo? https://github.com/osandov/drgn/issues/176
  -> Symbol tables implemented, kallsyms in review.
  -> Minimal BTF implementation, has some issues.
  -> CTF is used in production at Oracle.

* What is the "backend" of drgn? How could you glue kgdb into Drgn?
  -> The memory reader interface is the main way.
  -> In addition to implementing memory readers, you'd need a way to communicate the "vmcoreinfo" to drgn. This provides info such as kernel version and kaslr offset.
  -> We have a way to provide vmcoreinfo manually.
  -> we're discussing gdbstub options: https://github.com/osandov/drgn/wiki/gdbstub-protocol-proposal:-linux.vmcoreinfo-query-packet

* What's the minimum I need to do with root in drgn?
  -> just opening /proc/kcore

* Writing to kernel memory! New feature as of yesterday!
  -> See https://blog.osandov.com/2024/09/17/calling-linux-kernel-functions-from-userspace.html

Please join our Kernel Debuggers Matrix:
    https://matrix.to/#/#linux-debuggers:matrix.org
Please join our Kernel Debuggers Mailing List:
    linux-debuggers@vger.kernel.org

Re: LPC BoF - Linux Kernel Debugging & Drgn

[Stephen Brennan]

And for anybody who didn't join, we had this guide as a way to get
started with drgn, using a locally built kernel in virtme-ng:

https://gist.github.com/brenns10/2064f16ea9b18235b47038d78775410d

Stephen Brennan <stephen.s.brennan@oracle.com> writes:
> Hi everyone,
>
> Thank you for joining the BoF, by all indication it was quite
> successful, despite my apparent attempts at sabotage by changing the
> room last minute. I took notes as we went (though couldn't cover
> everything), which I've included below.
>
> Thanks,
> Stephen
>
> ---
>
> ​* Drgn within IPython notebooks!  Useful to help people follow & understand debugging sessions. -Shung-Hsi Yu
>
> * What is the criteria for "contrib/" vs "helpers/"? - Sweet Tea Dorminy.
>   -> Unit test cases!
>   -> Converting contrib/ to helpers/ is a valid and good on-ramp to drgn development.
>   -> Though, not all contrib scripts are expected to make it in.
>   -> There is also a "tools/" directory which is actually tested & supported.
>
> * Is there a "rosetta stone" comparison between operations in drgn and crash?
>   -> Not currently!
>   -> I (Stephen) have some which I could move out of an internal wiki into Drgn's wiki.
>
> * Drgn "commands" vs Crash commands. Drgn does not yet have a command structure, it's been discussed.
>
> * What is the status of drgn without debuginfo? https://github.com/osandov/drgn/issues/176
>   -> Symbol tables implemented, kallsyms in review.
>   -> Minimal BTF implementation, has some issues.
>   -> CTF is used in production at Oracle.
>
> * What is the "backend" of drgn? How could you glue kgdb into Drgn?
>   -> The memory reader interface is the main way.
>   -> In addition to implementing memory readers, you'd need a way to communicate the "vmcoreinfo" to drgn. This provides info such as kernel version and kaslr offset.
>   -> We have a way to provide vmcoreinfo manually.
>   -> we're discussing gdbstub options: https://github.com/osandov/drgn/wiki/gdbstub-protocol-proposal:-linux.vmcoreinfo-query-packet
>
> * What's the minimum I need to do with root in drgn?
>   -> just opening /proc/kcore
>
> * Writing to kernel memory! New feature as of yesterday!
>   -> See https://blog.osandov.com/2024/09/17/calling-linux-kernel-functions-from-userspace.html
>
> Please join our Kernel Debuggers Matrix:
>     https://matrix.to/#/#linux-debuggers:matrix.org
> Please join our Kernel Debuggers Mailing List:
>     linux-debuggers@vger.kernel.org