Conversation
Stephen Brennan
brenns10@snake.club
@ljs The libdrgn API is unstable, so there's not even a distro package anywhere that you could do #include <drgn.h> or -ldrgn right now.
That said, I know it gets internal use at Meta, and there are examples in the repo.
I've actually thought it would be interesting to combine libdrgn with a userspace BPF JIT that supports CO-RE, so we could use drgn's type system to resolve type references and execute BPF/kernel like (read-only) code at native speeds in userspace with drgn 🤔
0
0
0
Vlastimil Babka 🇨🇿🇪🇺🇺🇦
vbabka@mastodon.social
1
0
0
0
0
0
@ljs @vbabka @brenns10 no worries!
> Yeah libdrgn looked pretty dead to me in-repo so that's sad.
Almost all of drgn's core functionality is implemented in libdrgn first and only exposed via Python bindings, so it is very actively developed.
But @brenns10 is right, although we do have some internal users, it doesn't have a stable API or ABI and isn't installed by default.
That's mainly because no one has asked for that yet. I'd be very willing to do a bit of work to close the gap if it's important to you or anyone else.
> Yeah libdrgn looked pretty dead to me in-repo so that's sad.
Almost all of drgn's core functionality is implemented in libdrgn first and only exposed via Python bindings, so it is very actively developed.
But @brenns10 is right, although we do have some internal users, it doesn't have a stable API or ABI and isn't installed by default.
That's mainly because no one has asked for that yet. I'd be very willing to do a bit of work to close the gap if it's important to you or anyone else.
0
0
2
@ljs @vbabka @brenns10 the big caveat is that all of the helpers (e.g., for looking up VMAs) are indeed Python-only. Stephen and I have both had crazy ideas for using CO-RE or transpiling a subset of C to make things easier for people more comfortable with C like yourself, but that's probably a ways away.
0
0
3
@ljs @vbabka @brenns10 nope, we walk the maple tree (or red black tree on old kernels) ourselves: https://github.com/osandov/drgn/blob/89260b18b9fa01ffc7d5bfaedeb34aeec0198557/drgn/helpers/linux/mm.py#L1353. We have drgn helpers for walking both data structures, which are basically translations of the C kernel code. The maple tree ones were pretty fun: https://github.com/osandov/drgn/blob/89260b18b9fa01ffc7d5bfaedeb34aeec0198557/drgn/helpers/linux/mapletree.py#L67.
It wouldn't be _too_ hard to translate those to libdrgn, but it'd be tedious.
One other idea for C integration that comes to mind is adding a function to libdrgn that evaluates a string of Python code for you, that way you don't need to resort to system(). We could even have it return the drgn_object to C so you could use libdrgn to get the rest of the way. Would that help, or am I missing the point?
P.S. drgn does have a way to call kernel functions: https://drgn.readthedocs.io/en/latest/helpers.html#kmodify. But that's provided as a way for the user to shoot their own foot, it's too risky to use internally.
It wouldn't be _too_ hard to translate those to libdrgn, but it'd be tedious.
One other idea for C integration that comes to mind is adding a function to libdrgn that evaluates a string of Python code for you, that way you don't need to resort to system(). We could even have it return the drgn_object to C so you could use libdrgn to get the rest of the way. Would that help, or am I missing the point?
P.S. drgn does have a way to call kernel functions: https://drgn.readthedocs.io/en/latest/helpers.html#kmodify. But that's provided as a way for the user to shoot their own foot, it's too risky to use internally.
0
0
2
@ljs @vbabka @brenns10 @jann nah, we don't grab locks. Since we're read-only (ignoring kmodify), the worst that can happen is we follow some stale data and get a Python exception. But kmodify could be used for that if you really wanted.
Really cool that you made the kernel code work in userspace! I wished the Btrfs code could do that when I was working on Btrfs.
The tricky parts for using that code for the in-kernel data are 1) you need to translate memory accesses to reads from /proc/kcore 2) you need to match the appropriate version of the userspace code to the kernel version.
Really cool that you made the kernel code work in userspace! I wished the Btrfs code could do that when I was working on Btrfs.
The tricky parts for using that code for the in-kernel data are 1) you need to translate memory accesses to reads from /proc/kcore 2) you need to match the appropriate version of the userspace code to the kernel version.
0
0
3
