-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for built-in ORC information #460
base: main
Are you sure you want to change the base?
Changes from all commits
7e72870
278f004
b49d37d
2026435
44e10fd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1570,6 +1570,17 @@ drgn_module_wanted_supplementary_debug_file(struct drgn_module *module, | |
const void **checksum_ret, | ||
size_t *checksum_len_ret); | ||
|
||
/** | ||
* Return the object associated with this module. | ||
* | ||
* For Linux kernel loadable modules, this is a reference to the `struct module` | ||
* they represent. Other kinds of modules may have other objects. | ||
* | ||
* @param[out] ret Initialized object where the module object is placed | ||
*/ | ||
struct drgn_error * | ||
drgn_module_object(struct drgn_module *module, struct drgn_object *ret); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please also add a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It strikes me that this opens up the possibility for a user to assign a completely irrelevant object to the module, thus making it much more likely for an error to occur when we're using it. I don't have a problem with that, of course: good error handling is important regardless. But in my experience, sometimes errors that come from too deep within the bowels of drgn are no longer helpful, because they don't come with a stack trace like Python errors. For example here: if a user ran I know we can catch errors that we expect to be likely, and replace them with more informative ones. But I wonder if it wouldn't be worthwhile to add some sort of error-chaining functionality for drgn? That way, we could implement it so that any error returned by That's just an oddball idea which doesn't have to be part of this PR, in any case. And I could make the case against it as well: maybe we should rely on logging to give us the context for the error! Just an idea to ponder over the holidays. |
||
|
||
/** Debugging information finder callback table. */ | ||
struct drgn_debug_info_finder_ops { | ||
/** | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A pointer (i.e.
struct module *
) feels slightly more natural to me (following the precedent ofdrgn.Thread.object
). I'd be fine restrictingdrgn.Program.linux_kernel_loadable_module()
to only acceptstruct module *
and notstruct module
to make that simpler.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was thinking about that as well. I get that value pointers vs reference objects are always confusing to users, so I agree it would probably be better to stick with the convention that's already established.
I'd actually love to try to keep
linux_kernel_loadable_module()
acceptingstruct module
. If we can't create a pointer to the object, then we can just leave theModule.object
field absent as before. If you're ok with that.The reason being that I really enjoyed the possibility of somebody constructing a
struct module
value Object, and then passing it in. I don't actually know how feasible that would be, but it's kinda fun :)