Introduce ELF Backend type #941
Merged
Conversation
This file contains 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
For implementation peculiarities on Linux, we cannot make do with an ELF parser that unconditionally relies on memory mapped data. Rather, for certain /proc files we are actually forced to use file I/O instead. In order to switch between the two, introduce the Backend trait that abstracts over the differences between the two. In a nutshell, for the mmap backend we continue reading references to objects while for the file I/O based one we will work with owned objects instead. Signed-off-by: Daniel Müller <[email protected]>
So far our ELFN enumeration, which abstracts over the differences between 32 and 64 bit ELF types, was solely storing references. In the future, we are going to work with owned objects on some occasions. Store Cow objects instead of references inside ElfN to make that possible. Signed-off-by: Daniel Müller <[email protected]>
danielocfb
force-pushed
the
topic/elf-backend
branch
from
5e11302 to
9099050
Compare
In order to switch the ElfParser logic between memory mapped I/O and file I/O, parametrize it by the "backend" to employ. Using the Mmap backend will stay the default, as it is the more sensible option. Signed-off-by: Daniel Müller <[email protected]>
Now that our ELF logic is starting to become parametrized by the backend to use and no longer necessarily employs memory mapping, rename the 'mmap lifetime to 'elf to be a bit less misleading. Signed-off-by: Daniel Müller <[email protected]>
Similar to what we did for the ElfN enum, store a Cow object instead of a reference inside ElfNSlice. Doing so will allow us to abstract over the precise memory representation, which can change depending on the backend in use. Signed-off-by: Daniel Müller <[email protected]>
danielocfb
force-pushed
the
topic/elf-backend
branch
from
9099050 to
e2ab057
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #941 +/- ##
==========================================
- Coverage 94.56% 94.25% -0.32%
==========================================
Files 57 57
Lines 10527 10584 +57
==========================================
+ Hits 9955 9976 +21
- Misses 572 608 +36 ☔ View full report in Codecov by Sentry. |
Instead of unconditionally relying on memory mapped data in our ElfParser and Cache, switch over to using the recently introduced backend. The backend will transparently decide whether to work with references or owned objects. Signed-off-by: Daniel Müller <[email protected]>
Add some tests for our file I/O based ELF parser. Signed-off-by: Daniel Müller <[email protected]>
danielocfb
force-pushed
the
topic/elf-backend
branch
from
e2ab057 to
574ecc0
Compare
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.
For implementation peculiarities on Linux, we cannot make do with an ELF parser that unconditionally relies on memory mapped data. Rather, for certain /proc files we are actually forced to use file I/O instead. In order to switch between the two, introduce the Backend trait that abstracts over the differences between the two. In a nutshell, for the mmap backend we continue reading references to objects while for the file I/O based one we will work with owned objects instead.