elf2tab currently effectively uses a series of heuristics to choose which sections from an ELF to include in the TBF. These heuristics are based on a series of assumptions about 1) how the compilation toolchain created the ELF, 2) what types of sections are in Tock app binaries, and 3) what types of alignments and offsets will be present in the ELF. When elf2tab started, these assumptions were fairly strong (we only had a small number of hardware platforms, a single architecture, and a single toolchain), and therefore it was feasible to code the heuristics to get working TBF files.
Over time, however, Tock has expanded and many of the assumptions are no longer so narrow. We've been tweaking our heuristics to get working TBFs for a much wider set of input ELFs, but it is probably becoming increasingly untenable that our heuristics will continue to work across all platforms and toolchains.
This tracking issue is for a rewrite of how we pull sections from an ELF and include them in a TBF. If I'm not mistaken, we should be able to use the structure of the ELF format, and not our homegrown heuristics, to more universally generate TBFs.
At a high level, my understanding is that we should be:
Looping over ELF segments, identifying if those segments need to be in the TBF, and then choosing sections based on which sections are in those segments.
Respecting the padding and alignment constraints of segments and sections.
Keeping some method of handling PIC apps versus fixed address apps.
This doesn't need to necessarily be tied to this effort, but we do at some point need to think about maintaining alignment constraints with fixed address apps, as noted here: https://github.com/tock/tock/issues/3203. The issue here is that we don't have a way to tell the loader how it needs to align the overall TBF such that the actual code sections fall at the correct alignment.
bradjc
commented
1 year ago
elf2tabcurrently effectively uses a series of heuristics to choose which sections from an ELF to include in the TBF. These heuristics are based on a series of assumptions about 1) how the compilation toolchain created the ELF, 2) what types of sections are in Tock app binaries, and 3) what types of alignments and offsets will be present in the ELF. When elf2tab started, these assumptions were fairly strong (we only had a small number of hardware platforms, a single architecture, and a single toolchain), and therefore it was feasible to code the heuristics to get working TBF files.Over time, however, Tock has expanded and many of the assumptions are no longer so narrow. We've been tweaking our heuristics to get working TBFs for a much wider set of input ELFs, but it is probably becoming increasingly untenable that our heuristics will continue to work across all platforms and toolchains.
This tracking issue is for a rewrite of how we pull sections from an ELF and include them in a TBF. If I'm not mistaken, we should be able to use the structure of the ELF format, and not our homegrown heuristics, to more universally generate TBFs.
At a high level, my understanding is that we should be:
This doesn't need to necessarily be tied to this effort, but we do at some point need to think about maintaining alignment constraints with fixed address apps, as noted here: https://github.com/tock/tock/issues/3203. The issue here is that we don't have a way to tell the loader how it needs to align the overall TBF such that the actual code sections fall at the correct alignment.