Linking of ARM ELF fails in presence of .ARM.exidx section about patcherex2 HOT 2 CLOSED

@calebh Thank you for reporting it!

The short answer is I'm still currently working on this and will ideally get it done by Hackathon.
You can use ↓ for now (anywhere before apply_patches()) to manually mark certain unused functions as free space. Patcherex will then utilize this space to insert additional code, overwriting the original content.

proj.allocation_manager.add_free_space(addr, size, "RX")

We have received similar feedback through AMP Slack. In both instances, the root cause is Patcherex's attempt to allocate memory blocks at a distance from the patch site that exceeds the range a branch instruction can cover.

While implementing a solution for long-jump capabilities is on our agenda, a more pressing issue stems from how the ELF file is used for the board. Assuming the board in question is Teensy 4.1 (please correct me if I'm wrong), the process begins with converting the ELF file to Intel Hex format using objcopy. This is followed by loading it onto the board via Teensy's proprietary loader. This conversion process removes all segment/section information from the ELF file, and the behavior of the loader remains unclear. Consequently, this makes it challenging for Patcherex to identify appropriate memory addresses for injecting additional code based solely on the ELF or Hex file.

To mitigate this issue, I am developing a component that will extract relevant information from the linker script included in the Teensy toolchain. This enhancement will enable Patcherex to better comprehend the structure of the Teensy 4.1 ELF format. Following this, I plan to investigate the behavior of the firmware loader. In combination with the linker script extractor, this will enable Patcherex to accurately locate and allocate the correct positions for additional code.

from patcherex2.

#25

from patcherex2.