Hi !
We are writing an OS targeting 32 bits ARM platform, where binaries can be compiled in ARM or in Thumb mode.
At the moment, to execute a new process, I load the info from an ELF, set lr_usr to the entry point address, set spsr_usr to a default value (USER mode + I/F/A unmasked) and perform a 'movs pc, lr' to go to user mode.
So far, I only compiled my application in ARM mode. What if the ELF was compiled in thumb mode ?
I'm thinking about testing bit 0 of the entry point, and if it is set, add the T bit to spsr_usr, before executing the 'movs pc, lr' command.
Do I have to do this explicitly or will this be done by the movs pc, lr (because bit 0 of lr is 1) and I can ignore the T bit of the SPSR ?
Best regards,
V.
Hi vsiles,
Yes, but be warned that it's possible to set the ELF entry address to a value that would not reflect Thumb state but still always work if branched to.
Most operating systems (Linux, iOS, Windows..) that have mixed ARM and Thumb executables needfully prepend some startup code which is for ARM state (crt0.S or something similar, part of the C library), and it will then bounce correctly to Thumb code on it's own. That way the OS doesn't need to "guess" (and it will always be guessing..) based on the entry address. There's only one way to know for sure that the entry is Thumb, which is to align all entry points on a half-word boundary for Thumb apps (because this'd be impossible for ARM apps). You can't guarantee that bit 0 will be set by the linker in 100% of cases, especially if you override it with --entry (with the ARM compiler) or use a linker script that's not processing entry points the same way as branch (re-)locations (or has a hardcoded value).
Ta,
Matt
Ok, thank you !
We already have a crt0.S in ARM for our local devs, but some client might want to use their own, that's why I was wondering about detecting the kind of entry point we might face.
vsiles,
There are ways - it is mostly that ELF doesn't really give you the strictures needed to make a determination on it, and the amount of work you'd have to do to confirm it belies the simplicity of the issue. If you simply state that A32/T32 mixed code binaries must start in ARM state and make that part of your OS ABI, then it will be impossible for an app developer to do anything else (it'll crash rather than run), which is a pretty good compromise between OS complexity.