My plan is to use the correct width of the corresponding ELF types when parsing ELF structures
and then converting them into usize as appropriate when those fields are being interpreted
to locate other elf structures within in-memory buffers. For the common case these days
of 64-bit machines with 64-bit usizes, these conversions will all succeed. For 32-bit
machines, this conversion means that the library will not be able to parse large 64-bit
files. When that happens, though, the library should helpfully return an error instead of crashing.
These same sorts of changes will need to be made throughout the library in order to
harden it against crashing due to integer overflow math (often due to corrupted files).
Fuzzing catches this sort of thing really quickly.
Also, introduce two new resulting ParseError types:
TryFromIntError and IntegerOverflow
Note that the SysVHashTable::find() method does not currently take any symbol versioning
into account.
Also, add another sample elf file that contains a two versioned exported
symbols, a SHT_HASH section, a SHT_GNU_HASH section, GNU Symbol
Versioning sections, and .note.gnu.property and .note.gnu.build-id sections.
This skips the utf8 validation done in StringTable::get() and is helpful
for code that wants to interpret the raw bytes (such as for calculating hash values).
This didn't end up providing much value. As an interface, we want to be able
to be able to parse files with unknown section types the type had to allow
unknown values anyway. All it provided was an opinionated Display impl,
which can be easily recovered with sh_type_to_str() or sh_type_to_string()
This reduces a ton of boiler-plate code. It can also probably be reduced even
further with some macros, but I generally find macros add more cognitive overhead
than they're worth for simple tests like this. Maybe a project for another rainy day ;)
All of the uses validate the entsize as found in the file, so there's no need
to perform the duplicate validation again in the constructor. It's desireable
to do the validation before trying to get the buffer to back the table. So while
it'd be nice to have the table do the checking automatically for you, it happens
too late when done automatically that way.
There's no need to represent it as bytes in the actual table representation when
we've validated that it's a known constant for the given ELF class that we're parsing.
This is done by making each ParseAt type aware of the sizes based on the ELF class
via a new ParseAT::size_for(class) method, then adding validation checks based on that.
This output is opinionated in a way that is likely unhelpful for users of this
library. If someone is wanting to display FileHeader contents, they likely want
their own string formatting, and can construct it with the to_str helpers.
This output is opinionated in a way that is likely unhelpful for users of this
library. If someone is wanting to display ProgramHeader contents, they likely want
their own string formatting, and can construct it with the to_str helpers.
This output is opinionated in a way that is likely unhelpful for users of this
library. If someone is wanting to display SectionHeader contents, they likely want
their own string formatting, and can construct it with the to_str helpers.
This output is opinionated in a way that is likely unhelpful for users of this
library. If someone is wanting to display Symbol contents, they likely want
their own string formatting, and can construct it with the to_str helpers.
This has a few motivations:
* Move the big blocks of code dedicated to providing human readable strings for
gabi constants out of the way. This code can be long and distracting from the actual
parsing functionality.
* Allow users to opt out of this functionality if they don't need it. The big blocks
of &'static str definitions can add a fair amount to the resulting library size. For
users who are trying to optimize for library size, these to_str methods are often unneeded.
* The to_str method's Option return value allows users to decide how they want to display
unknown values.
The table has additional helpful features, like .get() to parse a given index in the table,
while still allowing access to the ParsingIterator interface via .iter()
Also remove dubiously helpful File::section_strings() method
If you want the strings, you probably also want the headers, so use the section_headers_with_strtab()
method.
The table has additional helpful features, like .get() to parse a given index in the table,
while still allowing access to the ParsingIterator interface via .iter()
New interfaces:
* Add File::symbol_version_table() interface to get the GNU extension symbol versioning table
* Add Symbol.is_undefined() helper to check if a symbol is defined in this object
* Add File::section_data() which opportunistically parses the CompressionHeader if present
Bug fixes:
* Fix StringTable to return a ParseError on index out of bounds instead of panicking
* Fix File::section_data_as_rels to properly parse Rels (not Relas)
Previously, it would forget to load and then just try to get the strings section data
This would work if some other processing on the file had already loaded the string table
but not if this was the first method that wanted to inspect those strings.
This class of bugs is really an integration with the CachedReadBytes interface, so it
can only get caught if we're testing with that impl. These interface tests should be parameterized
for both interfaces.
This is a zero-alloc interface which parses on-demand, which can be desireable if you can't
or don't want to allocate, but is less CPU-efficient if you're doing a lot of look ups on the table.
Christopher Cole