These are one type of entries found in the .gnu.version_r section of type SHT_GNU_VERNEED.
This only parses the type, and is not hooked up to anything else yet.
These other type of entries are found in the .gnu.version_d section of type SHT_GNU_VERDEF.
This only parses the type, and is not hooked up to anything else yet.
These type of entries are found in the .gnu.version_d section of type SHT_GNU_VERDEF,
alongside VerDefAux (not yet defined).
This only parses the type, and is not hooked up to anything else yet.
These are the entries found in the .gnu.version section of type SHT_GNU_VERSYM.
This only parses the entry type, and is not hooked up to anything in File yet.
I don't plan on implementing any actual compression as part of this library and think that
it is reasonable for users to do the decompression themselves based on the description
provided by the parsed CompressionHeader.
Also, deprecate File::section_data_for_header() in favor of section_data()
This header is found at the start of sections whose flags contain SHF_COMPRESSED,
indicating that the section's data in the file is compressed with a given algorithm.
These define possible values for the elf compression header's ch_type field, which
signals the compression algorithm used for compressed sections (shdr.sh_flags & SHF_COMPRESSED)
New Features:
* .note section and segment parsing
* .dynamic section and segment parsing
* .rel and .rela section parsing
* File::section_headers_with_strtab to get both a header iter and strtab concurrently.
This is useful if you want to iterate over shdrs and get their names at the same time.
Interface changes:
The ReadBytesAt trait was changed to be implemented for an owned CachedReadBytes.
This means that File::open_stream now expects to move-own the CachedReadBytes
as opposed to taking a mutable reference.
The implementation panned out where this header is parsed but then
only used to drive the further parsed Note but not included in the result,
so there's no need for pub(crate) here.
Note: (haha) It looks like gcc/clang choose to emit 32-bit note headers
even for 64-bit objects. I discovered this when writing the parse tests
with data from a 64-bit LSB ELF object that I slurped the .note.gnu.build-id
section from. I kept the 64-bit nhdr parsing around in case someone finds
a use-case for it in the future.
These fixed size headers prefix and describe variable-sized note data.
I made it pub(crate) to keep this out of the public interface, since
I plan to have the actual note iterator parse out the name and desc and
have that result be the actual public interface. pub(crate) might still
be more visibility than is needed, but it's a safe place to start.
This allows for a more convenient way of interacting with the SectionHeaders so
that you can concurrently look up the names of the sections as you're iterating
through the SectionHeaderIterator
Note, while this may satisfy some use-cases, it is likely insufficient for those
who want to actually do linking and to concurrently iterate over the returned Rels
while also looking at the sectin's associated SymbolTable and the section to which
they're applied.
I didn't have a strong motivating factor for deciding whether to represent this as I did,
with r_sym and r_type parsed out as data members, or as an alternative approach where
the rust type keeps a private r_info and then parses out those data members as needed with
getter methods. So I arbitrarily chose to parse them out up front.
As suggested in #21
This changes it from being implemented for a &mut CachedReadBytes, which forced
users to keep a separate variable for the reader when passing it to File::open_stream().
There wasn't a specific reason for it to be implemented that way, and it's actually
something that tenuously even desireable, since ultimately CachedReadBytes is
a more an internal wrapper used within the File for lazy parsing than something
that a user of the interface will want to keep around and use themselves for other things.
This centralizes the iter implementation to one place and leverages the new ParseAt
trait which was already functionally being implemented by all the various types
being iteratively parsed.
ELF Object files can have either or both a ProgramHeader and SectionHeader that
describes how to locate the .dynamic entries in the file. We try the SectionHeaders
first, and if there are none (a loadable-only ELF object) then we check for it in
the ProgramHeaders. It is also Ok for there to be no .dynamic entries in the file.
Now, all section parsing is done lazily on-demand by the other File methods
Also, update README.md and lib.rs doc comment to reflect current library development state
These use the lazy parsing methods to read the section headers and section data when requested
as opposed to reading and parsing the section headers and section data all up front when the File
is created.
