Allow naming and configuring order of type, object, and symbol finders

[osandov]

Commit 2 has more details, but the idea is that you'll now be able to do something this:

>>> def bpf_symbol_finder(name, address, one):
...     ...
...
>>> prog.register_symbol_finder("bpf", bpf_symbol_finder)
>>> prog.registered_symbol_finders()
{'elf', 'bpf'}
>>> prog.enabled_symbol_finders()
['elf']
>>> prog.set_enabled_symbol_finders(["elf", "bpf"])
>>> prog.enabled_symbol_finders()
['elf', 'bpf']

[brenns10]

1. I really like the idea of disabling the finders without removing them, since removing a finder has difficult considerations regarding the lifetimes of the symbols associated with it. This sidesteps the problem nicely, while still allowing users to ignore a finder, which is pretty cool.

2. Similar feelings about reordering finders! That's great :D

3. One interesting note is that your BPF symbol finder is just a standalone function, whereas most of the finders I've written aren't just a function, they have some state (e.g. parsed kallsyms). So they are typically a class instance that's returned after some initialization, and that initialization may even require some arguments (e.g. addresses of kallsyms tables). That's not necessarily a problem, but it doesn't fit as neatly into the plugin vision you described in the second commit. It could be that we'd just "register" some sort of proxy object that initializes itself when you first use it, or first enable it?

[osandov]

My vague idea for plugins is that they'd be .py files in /etc/drgn/plugins.d and/or ~/.config/drgn/plugins.d that define a hook which gets passed prog after it has been set up. That hook can then set up stuff like finders and debug info callbacks.

In a world like that, using this interface, a plugin could create and register a symbol finder instance specifically for a given Program, and it could lazily initialize itself on the first call just like you said. E.g., a BPF symbol finder that caches the symbols would work nicely.

Anything that needs manual configuration from the user (like the kallsyms finder if VMCOREINFO doesn't have the symbols, I assume?) I don't think is going to work in a plugin model, anyways. For that, the finder instance can always be registered and enabled explicitly.

[brenns10]

Yeah, I think some things won't work in that model, but it's certainly not worth throwing out the baby with the bathwater, because it seems useful on its own already.

[brenns10]

Sorry for not actually taking a closer look at the code until now! I like the idea, and the code looks great.

[brenns10]

It might make sense to have a cleanup callback here.

if (handler->cleanup)
    handler->cleanup(handler->cleanup_arg);
if (handler->free) {
    free((char *)handler->name);
    free(handler);
}

This would provide a natural way for handlers to properly clean up when the program gets destroyed, and the logic could be shared for all types of handlers. Right now, the symbol finders I've shared in #388 get cleaned up by the decref of their Python object, so they wouldn't need it.

But pure-C finders which may not be directly exposed with a Python object (such as the CTF type & object finder), they won't be able to take advantage of this cleanup mechanism. In fact, my CTF branch currently adds a drgn_ctf_destroy() callback inside drgn_program_deinit() to handle cleanup properly, so this would be helpful.

In any case, you probably shouldn't include an API without a user in this PR, but I just thought I'd bring it up as a possible direction for this.

[osandov]

I reworked the generic handler list to be smaller and converted type and object finders, too. I'll skim back through to make sure I didn't mess anything up and merge this tomorrow.

[osandov]

Oh, I totally forgot about the cleanup thing. I'll add that tomorrow.