Repository navigation
linux: separate mappings list from modules list - #212
Merged
schopin-mozilla merged 2 commits intoAug 31, 2026
Merged
Conversation
Collaborator
Author
|
Ping @marti4d for review. Sorry, it's a bit massive :/ |
schopin-mozilla
force-pushed
the
module-refactor
branch
3 times, most recently
from
August 18, 2026 17:03
ec61b3f to
82a8ba6
Compare
schopin-mozilla
force-pushed
the
module-refactor
branch
2 times, most recently
from
August 21, 2026 20:40
9e48fdd to
3d771d0
Compare
schopin-mozilla
force-pushed
the
module-refactor
branch
from
August 26, 2026 14:07
3d771d0 to
214fb77
Compare
gabrielesvelto
approved these changes
Aug 31, 2026
Contributor
There was a problem hiding this comment.
Sorry, I meant to have approved this with nits so you can merge when they're addressed
While both things are related to each other, and for now we're using the former to generate the latter, they are essentially two different sets of data, meant to answer two different questions. Since the endgoal of this patch series is to use a *different* data source for the module info, the first step is to actually make it its own entity. My design goal for this is to only construct ModuleInfo objects once we know they're correct (or as correct as they are), which is why we moved the user-supplied mapping processing right within the process, and it all goes through an intermediate struct. There's a couple of advantages to this: we have all module-related logic stored in a single place, including arbitration between user-provided and process-derived data, and if you get a ModuleInfo object you know it's the same data that will get written out. An unplanned benefit of this is that mappings don't need to know about bias anymore, which is nice since it's an ELF notion, not a generic mapping one. The final result should be the same as before, except for one case: conflicts between process-derived and user-provided data is now explicitly handled, with the latter given priority. Additionally, errors during SONAME extractions are now reported in the soft error stream rather than completely ignored. It's a bit tangential, but was entangled too much with the rest to be split out into its own commit.
We don't need to remember the "true" range for mapping anymore, because it never changes!
schopin-mozilla
force-pushed
the
module-refactor
branch
from
August 31, 2026 16:26
214fb77 to
e687a02
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While both things are related to each other, and for now we're using the
former to generate the latter, they are essentially two different sets
of data, meant to answer two different questions. Since the endgoal of
this patch series is to use a different data source for the module
info, the first step is to actually make it its own entity.
My design goal for this is to only construct ModuleInfo objects once we
know they're correct (or as correct as they are), which is why we moved
the user-supplied mapping processing right within the process, and it
all goes through an intermediate struct. There's a couple of advantages
to this: we have all module-related logic stored in a single place,
including arbitration between user-provided and process-derived data,
and if you get a ModuleInfo object you know it's the same data that will
get written out.
An unplanned benefit of this is that mappings don't need to know about
bias anymore, which is nice since it's an ELF notion, not a generic
mapping one.
The final result should be the same as before, except for one case:
conflicts between process-derived and user-provided data is now
explicitly handled, with the latter given priority.
Additionally, errors during SONAME extractions are now reported in the
soft error stream rather than completely ignored. It's a bit tangential,
but was entangled too much with the rest to be split out into its own
commit.
(description lifted from the first and most meaty commit, the second one being just some cleanup.)
(split off #195)