Revert "Generate segment padding from ELF-internal offsets"

[lschuermann]

This reverts commit d89f703. Ultimately, the underlying issue motivating these changes seems to be a linker bug, as documented in libtock-rs PR tock/libtock-rs#477 1. Indeed, we should follow the physical addresses as specified in the ELF file to generate padding, meaning that the previous code was correct.

However, there's two invariants which elf2tab should ensure still:

• the libtock-rs bug seems to indicate that the section placement in ELF files does not necessarily have to correlate to their physical (load) address. It appears to be valid for ELF files to list sections in an arbitrary order, and thus elf2tab should presumably sort sections by their physical address (intended load address), and then walk them and insert padding as necessary.

• the confusing behavior which lead to this incorrect bugfix was that elf2tab generated a very large (> 256MB) TBF. To ensure that this does not happen, we can introduce sanity checks.

  elf2tab acts as the Tock application loader, by placing apps into memory such that they can be executed in place. This means that the physical address of all LOADed segments must be within the board's FLASH address space. We can have elf2tab issue a warning if there is an excessive amount of space (>= 4kB) between the physical (load) end address of one segment, and the start address of the next. This prevents linker script bugs from creeping into elf2tab undetected, and cause it to blindly generate nonsensical binaries.

[lschuermann]

In addition to reverting the incorrect change, I've inserted two assertions that generate warnings when certain invariants are violated:

• if elf2tab's calculations indicate that negative padding is required, segments are likely not ordered by their PhysAddr in the ELF file. We don't handle this case yet by reordering segments, as I'm not 100% sure that this won't break things.

• if elf2tab would generate >= 4096 bytes of padding (where 4096 bytes is the default alignment of ELF segments), we warn the user that we're inserting a large amount of padding. This may happen when the PhysAddr of a segment in the ELF file is incorrect, and points (for instance) to the RAM address instead of the flash memory section. This is not supported by elf2tab, as it is a flash loader and Tock does not perform dynamic loading.

Thus, running elf2tab on the broken ELF files of tock/libtock-rs#477 (generating a > 256MB TBF) yields the following output:

  Warning! Inserting a large amount of padding.

Running elf2tab on a libtock-rs ELF without the changes of tock/libtock-rs#478 yields the following output:

  Warning! Expecting ELF sections to be in physical (load) address order.
           Not inserting padding, the resulting TBF may be broken.

elf2tab keeps quiet on innocent & correct libtock-rs and libtock-c ELFs.