Ticket #310 (Fixed)Sat Sep 01 12:45:34 UTC 2012
Link doesn't set bit 31 of the AIF header
| Reported by: | Sprow (202) | Severity: | Minor |
| Part: | RISC OS: C/C++ toolchain | Release: | |
| Milestone: | Status | Fixed |
Details by Sprow (202):
castle/RiscOS/Sources/SystemRes/Patch (becomes module ‘AppPatcher’) inspects bit 31 to know that the given application has been compiled as StrongARM compatible, however the linker doesn’t seem to flag this.
Perhaps this was an oversight that was later retracted?
So:
Either that flag bit needs reserving so it doesn’t get reused for some other purpose and thus cause apps to go unpatched;
Or it should be set (perhaps as simply as ‘if it’s 32 bit then it must be StrongARM happy’?).
Changelog:
Modified by Ben Avison (25) Sun, March 09 2014 - 22:12:10 GMT
It’s hard to know from where the linker could be expected to get the knowledge that the component object files it was linking together were all StrongARM-compatible. Acorn/Codemist/ARM never defined a StrongARM-compatible AOF area flag, although they did add a 32-bit APCS flag which informs the linker’s choice of the bottom byte of the AIF flags word.
Bit 31 of the AIF flags word isn’t defined in the headers used to build the tools, and it’s not mentioned in the AIF documentation that accompanies the C tools either (only bit 8 is mentioned; this is set if you used -rw-base on the link command line). Are you aware of it being mentioned anywhere else apart from inside AppPatcher (where I note it’s not even given a symbolic name)?
My feeling is that this particular ship has sailed. Any new code being built should be compiled APCS-32 nowadays, and no APCS-32 code should ever have been not-StrongARM-safe. Retrospectively adding extra APCS variants to all the tools and adding a corresponding AOF flag, just so the linker can set an AIF flag differently, in order to skip some AppPatcher functionality seems like a lot of effort to remove some potentially useful functionality – StrongARM wasn’t the last change to the ARM architecture which results in a requirement to change applications.
Modified by Sprow (202) Tue, March 18 2014 - 08:49:53 GMT
OK, so it sounds like bit 31 was cooked up by one person but never communicated to the tools department (way back in 1997). I’ve never seen any references to it in other docs either.
If the linker only knows about flag bits up to 8 then it’ll be some decades before flag bit 31 is needed. Currently AppPatcher is only loaded by the boot sequence for RISC OS < 500 and is built 26 bit only and lives in !System/370.
So how about I just change AppPatcher to skip the StrongARM patch checks if the bottom 8 bits are ‘32’ based on your “no APCS-32 code should ever have been not-StrongARM-safe” comment? Or even just delete the check altogether on the basis that the code signatures wont match anyway?
Modified by Sprow (202) Thu, May 08 2014 - 22:24:33 GMT
> Are you aware of it being mentioned anywhere else apart from inside
> AppPatcher (where I note it’s not even given a symbolic name)?
Found one, page 6, application note 295
“Scanning an application for code sequences is a relatively slow operation. Therefore a bit has been allocated in the AIF header to indicate that a program is “StrongARM-ready”. If bit 31 of the 13th word of the AIF header (ie bit 31 of location &8030 in the loaded image) is set, the patching stage will be skipped"
Modified by Steve Revill (20) Wed, May 14 2014 - 20:30:01 GMT
Yes – please go ahead with the AppPatcher change that you suggested. We’ll forget about the other bit because we’re never going to implement that in our tools.
Modified by Sprow (202) Mon, May 19 2014 - 20:29:45 GMT
- Status changed from Open to Fixed
Patch-0_08 removes the bit 31 check.
