Add support for Fast FAP loading

[str4d]

flipperdevices/flipperzero-firmware#2790 bumps the SDK to 31 with 15x faster loading of FAP files. It requires adding .fast.rel sections, so we will need to alter flipperzero-rt to enable it.

[dcoles]

Looking at the PR, I think what it's doing is creating a hash table for symbol lookup, rather than a linear search.

This might need to be done as some sort of post-processing step as I don't think it's possible to do this in build.rs or the linker script. This appears to be what scripts/fastfap.py is for.

[DrZlo13]

Yep, fastfap.py is post-processing elf files not only for hashing (also, this does not affect the speed, it is size optimization), but also to create an optimized relocation structure for our elf loader. This removes a large number of calls to the storage, and that's how such an acceleration is achieved.

Instead of "Each offset in .rel refers to .sym, then .sym refers to .symstr, and then we get a hash for the string from .symstr and then we apply this single relocation" we now have ".fast.rel, which contains a hash of the function name and offset, where this relocation needs to be applied”.

I recommend you to wait until this feature is released because the format of these sections is subject to change. I also left a fallback to the old usual linking process if optimized sections is not present.

[dcoles]

@DrZlo13 Thanks for the information. Definitely appreciate the fallback, so this isn't an urgent thing to address.

[str4d]

This was released in firmware version 0.86.1, and once #93 merges we will require at least 0.87.0, so we can start working on this.

[str4d]

This is now implemented in #99. I think I got the encodings right, and it appears to work (cargo test gets noticeably faster) but I'm unsure if the MD5 for tempfile names in fastfap.py is just for convenience or meant to be load-bearing.

[DrZlo13]

@str4d MD5 there is only for reducing filename size. Not all filesystems can handle files named from a C++ generated section name.

[str4d]

@DrZlo13 thanks, that clarifies things (I didn't know objcopy derives section names from filenames in this way - EDIT: I misread due to jetlag; I think this is actually about the build filesystem and has no effect on the FAP?).

I expect that means my current PR is adopting section names from the random file name being chosen by NamedTempFile, which defaults to .tmp<6_RANDOM_CHARS>. Making it deterministic on the section name seems like a better approach.