b[l]x instruction in cortex-m3 code

b[l]x instruction in cortex-m3 code

[Daniel Otte]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

Hi,
when I link code for the ARM Cortex-M3 the b[l]x instruction is emitted.
Since Cortex-M3 has no ARM mode and no b[l]x instruction the CPU goes in a fault
mode when it is asked to execute it.

As far as I have read it is ok for the compiler to emit b[l]x but the linker is
required to translate it into b[l] instructions.

I tried a lot of linker flags with no success.

Are I'm missing something or is this really a bug?

Best regards,
  Daniel Otte


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: b[l]x instruction in cortex-m3 code

[Daniel Jacobowitz]

On Mon, Jul 18, 2011 at 4:03 PM, Daniel Otte <daniel.otte@rub.de> wrote:
> Hi,
> when I link code for the ARM Cortex-M3 the b[l]x instruction is emitted.
> Since Cortex-M3 has no ARM mode and no b[l]x instruction the CPU goes in a fault
> mode when it is asked to execute it.
>
> As far as I have read it is ok for the compiler to emit b[l]x but the linker is
> required to translate it into b[l] instructions.
>
> I tried a lot of linker flags with no success.

Typically this means you are calling a function that is not correctly
marked as Thumb code, so the linker is helpfully switching you back to
ARM mode; check the target symbol.

-- 
Thanks,
Daniel

Re: b[l]x instruction in cortex-m3 code

[Daniel Otte]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Hi

> Typically this means you are calling a function that is not correctly
> marked as Thumb code, so the linker is helpfully switching you back to
> ARM mode; check the target symbol.
> 
That was also my first thought, but it happens also with calls in the same file.
So the code:

------------------------------------------------------------

typedef void(*fpt)(int);

void func(int a){
	a = a*a;
}

int main(void){
	fpt p;
	p = func;
	p(3);
	for(;;)
		;
	return 0;
}

------------------------------------------------------------

compiles to:

------------------------------------------------------------

000001b0 <func>:
 1b0:   b480            push    {r7}
 1b2:   b083            sub     sp, #12
 1b4:   af00            add     r7, sp, #0
 1b6:   6078            str     r0, [r7, #4]
 1b8:   687b            ldr     r3, [r7, #4]
 1ba:   687a            ldr     r2, [r7, #4]
 1bc:   fb02 f303       mul.w   r3, r2, r3
 1c0:   607b            str     r3, [r7, #4]
 1c2:   f107 070c       add.w   r7, r7, #12
 1c6:   46bd            mov     sp, r7
 1c8:   bc80            pop     {r7}
 1ca:   4770            bx      lr

000001cc <main>:
 1cc:   b580            push    {r7, lr}
 1ce:   b082            sub     sp, #8
 1d0:   af00            add     r7, sp, #0
 1d2:   f240 13b1       movw    r3, #433        ; 0x1b1
 1d6:   f2c0 0300       movt    r3, #0
 1da:   607b            str     r3, [r7, #4]
 1dc:   687b            ldr     r3, [r7, #4]
 1de:   f04f 0003       mov.w   r0, #3
 1e2:   4798            blx     r3
 1e4:   e7fe            b.n     1e4 <main+0x18>
 1e6:   bf00            nop

------------------------------------------------------------

I especially took a look at the implementation of the function pointer call.
But also the normal funtion returns with a bx.

Best regards,
  Daniel Otte


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: b[l]x instruction in cortex-m3 code

[Dave Martin]

On Mon, Jul 18, 2011 at 10:49 PM, Daniel Otte <daniel.otte@rub.de> wrote:
> Hi
>
>> Typically this means you are calling a function that is not correctly
>> marked as Thumb code, so the linker is helpfully switching you back to
>> ARM mode; check the target symbol.
>>
> That was also my first thought, but it happens also with calls in the same file.
> So the code:
>
> ------------------------------------------------------------
>
> typedef void(*fpt)(int);
>
> void func(int a){
>        a = a*a;
> }
>
> int main(void){
>        fpt p;
>        p = func;
>        p(3);
>        for(;;)
>                ;
>        return 0;
> }
>
> ------------------------------------------------------------
>
> compiles to:
>
> ------------------------------------------------------------
>
> 000001b0 <func>:
>  1b0:   b480            push    {r7}
>  1b2:   b083            sub     sp, #12
>  1b4:   af00            add     r7, sp, #0
>  1b6:   6078            str     r0, [r7, #4]
>  1b8:   687b            ldr     r3, [r7, #4]
>  1ba:   687a            ldr     r2, [r7, #4]
>  1bc:   fb02 f303       mul.w   r3, r2, r3
>  1c0:   607b            str     r3, [r7, #4]
>  1c2:   f107 070c       add.w   r7, r7, #12
>  1c6:   46bd            mov     sp, r7
>  1c8:   bc80            pop     {r7}
>  1ca:   4770            bx      lr
>
> 000001cc <main>:
>  1cc:   b580            push    {r7, lr}
>  1ce:   b082            sub     sp, #8
>  1d0:   af00            add     r7, sp, #0
>  1d2:   f240 13b1       movw    r3, #433        ; 0x1b1
>  1d6:   f2c0 0300       movt    r3, #0
>  1da:   607b            str     r3, [r7, #4]
>  1dc:   687b            ldr     r3, [r7, #4]
>  1de:   f04f 0003       mov.w   r0, #3
>  1e2:   4798            blx     r3
>  1e4:   e7fe            b.n     1e4 <main+0x18>
>  1e6:   bf00            nop
>
> ------------------------------------------------------------
>
> I especially took a look at the implementation of the function pointer call.
> But also the normal funtion returns with a bx.
>
> Best regards,
>  Daniel Otte
>
>

Can you retry, passing the -v argument to gcc so that all the
compiler, assembler and linker options are all printed out?

IIUC, blx <label> is not relocatable and shouldn't be emitted by the
compiler unless compiling for a target which supports it.  It should
also never be emitted for a preemptible or unknown destination symbol.
 The linker may translate a relocatable B <label> or BL <label> into
BX <label> or BLX <label> (or may insert a veneer which does this) at
link time if some functions are mis-annotated as ARM when they should
be Thumb.

blx <Rm> _is_ the preferred way to do all indirect function calls, at
least on ARMv7-[AR], but I'm not so familiar with the M profile.  I
would be surprised if bx <Rm> and blx <Rm> are not supported by the M
profile, but blx <label> makes no sense on that architecture and is
unlikely to be supported.  I could be wrong though -- I don't have the
documentation in front of me right now.

Cheers
---Dave

Re: b[l]x instruction in cortex-m3 code

[Daniel Jacobowitz]

(Without HTML this time)

On Mon, Jul 18, 2011 at 5:49 PM, Daniel Otte <daniel.otte@rub.de> wrote:
> That was also my first thought, but it happens also with calls in the same file.

No, this is something else.

>  1d2:   f240 13b1       movw    r3, #433        ; 0x1b1
>  1d6:   f2c0 0300       movt    r3, #0

Notice the low bit set here.

>  1e2:   4798            blx     r3

Both bx reg and blx reg use mode based on the reg's low bit; they are
perfectly fine on Cortex-M.  But if you give them an invalid argument,
they'll fault.

-- 
Thanks,
Daniel