[fpc-devel] Capability CPUARM_HAS_BLX_LABEL with ARM instruction set

[Jeppe Johansen]

On 12/16/2015 10:13 AM, Jonas Maebe wrote:
> Anthony Walter wrote:
>> Because these devices have a fairly large amount of memory I have been
>> using ARM instruction set (-CIARM option) to simplify the assembler code
>> required for the low level interfaces, however early on I noticed that
>> if I specify the options -CpARMV7A (or -CpARMV6) and –CIARM I end up
>> with code that doesn’t work.
>>
>> I traced the problem to the use of BLX <Label> instructions which
>> according to the ARM documentation seem to always causes an
>> unconditional change to Thumb state. If I remove the
>> CPUARM_HAS_BLX_LABEL capability and rebuild the compiler the code
>> produced uses only BL <Label> and always works correctly. There seems to
>> be no problem with BLX <Register> or BX <Register> instructions which
>> use bit[0] of the register to determine the target state.
>
> The compiler and assembler mark which code is ARM and which is Thumb. 
> Normally, when the linker processes the object files, it will replace 
> the blx instructions with bl if they go from ARM to ARM or from Thumb 
> to Thumb. The reason that a compiler/assembler cannot do this, is that 
> the target of a call may be in another object file and the 
> compiler/assembler cannot know whether this object file has been 
> compiled in ARM or Thumb mode.
>
> Are you not processing the generated code with a linker at all?
>
>
> Jonas
Just adding to Jonas's answer here.

While it's true that BLX always changes instructions set, I've heard 
some reports indicating that some assembler/linker combinations on OSX 
(apparently clang based?) have been behaving strangely with this lately.
GCC+binutils have always been following the "emit blx and let the linker 
fix it" recipe, just as fpc does.

Best Regards,
Jeppe