I agree, programmatic access to hashes could be useful, I don't see much reason to expose it in UI. File browser size/timestamp is usually good enough.
Even if this has value, I don't see a need for many hash implementations. We aren't worried about cryptographic security here.
If it was available from script, then people who really needed it for some reason could use a script. I can think of a few uses to having it in script.
It's not a matter of what the camera supports, neither gcc nor elf2flt no anything about that.
I'm sorry I didn't clarify. The code would build, but the File Browser won't start.
Did you do a full build (make clean all)?
I'm assuming I don't have to re-upload DISKBOOT.BIN, since this is an assembly command. Am I wrong?
You would need to re-upload DISKBOOT.BIN, because the added gcc builtin function would be in the core.
As explained in the comments in the .inc file this is the whole point of ABI exports: To have one copy of the gcc builtins in the core, rather than attached to each module.
As long as the compiler is given the correct CPU flags (which AFAIK, it is), it should not generate instructions the CPU cannot execute, and if it did, the result would be a crash not the module failing to load. The builtins are specifically there to implement operations
not supported by the CPU instruction set, i.e. division, floating point, 64 bit integer...