Previously, segment.p_addr was used to generate offsets. Given a specific ordering of ELF segments and certain target memory layouts, this has been observed to insert very large paddings (~256MB), which further break internal offsets in the binary. Instead of the target's addresses, we should be using ELF-file internal offsets to infer padding between segments (which means that the TBF-internal offsets should be equivalent to those of the ELF file itself).
Testing Strategy
I've tested this with a libtock-rs application using a bunch of different linker configurations. Throughout all of these configurations, with this change, elf2tab seems to produce binaries that matched the ELF's contents (although some of these apps were still broken for unrelated reasons). Tested with a few libtock-c apps as well, although without any linker script changes.
Pull Request Overview
Previously,
segment.p_addrwas used to generate offsets. Given a specific ordering of ELF segments and certain target memory layouts, this has been observed to insert very large paddings (~256MB), which further break internal offsets in the binary. Instead of the target's addresses, we should be using ELF-file internal offsets to infer padding between segments (which means that the TBF-internal offsets should be equivalent to those of the ELF file itself).Testing Strategy
I've tested this with a
libtock-rsapplication using a bunch of different linker configurations. Throughout all of these configurations, with this change,elf2tabseems to produce binaries that matched the ELF's contents (although some of these apps were still broken for unrelated reasons). Tested with a fewlibtock-capps as well, although without any linker script changes.