See gimli-rs/addr2line#170 for an example of an ELF file with incorrect section header alignment.
We've got a few options for how to handle this:
- Do nothing. Fix your toolchain instead. This option is okay for narrow use cases where we have control of the toolchain, but not suitable for a general purpose library.
- Always handle any alignment. This means that on some architectures we'll generate slower code, which may be undesirable for use cases where we know the alignment is correct.
- Relax the alignment constraints as needed. For the ELF file, we would change
SectionHeader64 to only use types that require 4-byte alignment.
- Add a compile time feature to select whether to support any alignment. This could be done by ensuring that types like
U32 and U32Bytes have the same API, and making U32 an alias of U32Bytes when this feature is enabled. I think the only downside is that this prevents supporting both cases in the same application.
- Add a trait parameter to all of the structs so that the application can decide which to support. This is unnecessary complication if one of the other options is good enough.
See gimli-rs/addr2line#170 for an example of an ELF file with incorrect section header alignment.
We've got a few options for how to handle this:
SectionHeader64to only use types that require 4-byte alignment.U32andU32Byteshave the same API, and makingU32an alias ofU32Byteswhen this feature is enabled. I think the only downside is that this prevents supporting both cases in the same application.