Add drgn.helpers.drgn

[brenns10]

Ok, so I know that this was a joke, but it's... still kinda useful. I think the print_type_report() function is genuinely helpful (though it could probably do a bit better at representing the type). Also, I've added an undocumented --debug-self option which will create a Program pointing at the current task, and initialize a variable oot (object of test) to represent the program that drgn launched as part of the CLI. With that, you can actually quite quickly do some useful analysis.

I added these helpers to the docs, but I put them into a separate page named "Development Helpers", and I made sure that it was clear that the helpers may not be stable. If the helpers had been included in the main "Helpers" page, they would have sorted above the Linux helpers, which is definitely not okay.

Anyway, here's an example using them. It's fun. Yeah it's kinda for the meme. No pressure to actually merge it :P

$ python -m drgn -c ../drgn-tools/testdata/vmcores/rds-uek7/vmcore -s ../drgn-tools/testdata/vmcores/rds-uek7/vmlinux --debug-self
drgn 0.0.29+45.g602fb71a (using Python 3.9.19, elfutils 0.191, with libkdumpfile)
warning: missing some debugging symbols (see https://drgn.readthedocs.io/en/latest/getting_debugging_symbols.html):
  kernel modules (could not read depmod: open: /lib/modules/5.15.0-9.96.5.el8uek.x86_64/modules.dep.bin: No such file or directory)
For help, type help(drgn).
>>> import drgn
>>> from drgn import FaultError, NULL, Object, alignof, cast, container_of, execscript, implicit_convert, offsetof, reinterpret, sizeof, stack_trace
>>> from drgn.helpers.common import *
>>> from drgn.helpers.linux import *
>>> from drgn.helpers.drgn import *

>>> self_prog = program_from_self()
>>> oot = get_prog_obj(self_prog, prog)
>>> print_type_report(oot)
   0 struct module (0x55c163ff7e40)
   1 struct list_head (0x55c163fedd70)
   2 struct list_head (0x55c1642d6430)
   3 struct module_layout (0x55c1643e8150)
>>> print_disks(prog)
251:0 vda (struct gendisk *)0xffff9d17d023d600
11:0 sr0 (struct gendisk *)0xffff9d17c0a52000
252:0 dm-0 (struct gendisk *)0xffff9d17c1043400
252:1 dm-1 (struct gendisk *)0xffff9d17c1040600
252:2 dm-2 (struct gendisk *)0xffff9d17c0fa8600
>>> print_type_report(oot, start=4)
   4 struct class (0x55c1641a94c0)
   5 struct kset (0x55c164225fd0)
   6 struct list_head (0x55c16430a500)
   7 struct subsys_private (0x55c165435ed0)
   8 struct kset (0x55c1653f23b0)
   9 struct kobject (0x55c16401a470)
  10 struct list_head (0x55c1641958e0)
  11 struct class (0x55c16543b180)
  12 struct klist (0x55c165578b00)
  13 struct device_private (0x55c163fdf330)
  14 struct klist_node (0x55c165549a00)
  15 struct device (0x55c1643a7180)
  16 struct block_device (0x55c165482ed0)
  17 struct device (0x55c164120800)
  18 struct gendisk (0x55c165431590)

In particular, it's interesting how the struct list_head gets included at index 1, 2, 6, and 10. So maybe there's an opportunity for improving caching there. Similarly with kset at index 5 and 8, and device at index 15 and 17.