Can thumb interwork be deactivated on CW 10.6 with ARM toolchain?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can thumb interwork be deactivated on CW 10.6 with ARM toolchain?

Jump to solution
660 Views
niflheims
Contributor II

Hello,

I am running into a crash related to thumb-interwork. My code runs on a MK21FN1M0M12 (Cortex-M4, arm-v7m).

Since arm-v7m only supports thumb2, using thumb-interwork does not seem to make sense.

 

All the code is generated in thumb instructions. I am using CodeWarrior for MCU v10.6 with the ARM toolchain.

I get trouble when making an indirect function call, through a pointer. The function code gets an odd address at link stage, which is OK (indicates it is thumb code). However, when calling it through a pointer, a BLX instruction gets generated (I suppose the linker updates the original BL into a BLX here) AND the function pointer's value remains even! Since the pointer value remains even, the jump instructs the core to switch to ARM mode. Hence the crash.

 

I think the linker upgrades the BL into a BLX because of the thumb-interwork feature being activated. On CodeWarrior for MCU v10.6, this is forced, I cannot disable it. I am told that this is "required for processor" and cannot click the checkbox (Properties->C/C++ Build->Settings, ARM CPU. The processor is set to "cortex-m4").

 

I do not understand why, since this is arm-v7m. Moreover it seems to lead me into trouble. I think I am missing something here.

 

Could you please help me understand what is going on and/or tell me how to disable thumb-interwork on CodeWarrior?

 

Thanks and best regards,

Pierre

Labels (1)
0 Kudos
1 Solution
457 Views
niflheims
Contributor II

My question was a bit of an XY problem, sorry for that.

My problem arose from using libraries built with GCC with CodeWarrior configured to use the Freescale's toolchain (ARM tools).

The function pointer with the LSB not set came from one of those libraries and was valued at the link stage by CodeWarrior. Since the linker properly put every function from those libs at odd addresses, I guessed that it should miss some information to detect that the faulty pointer was actually a function pointer.

Long story short, it turned out that the libraries were stripped, especially with the --strip-unneeded flag. I removed that flag and the linker did a perfect job!

View solution in original post

1 Reply
458 Views
niflheims
Contributor II

My question was a bit of an XY problem, sorry for that.

My problem arose from using libraries built with GCC with CodeWarrior configured to use the Freescale's toolchain (ARM tools).

The function pointer with the LSB not set came from one of those libraries and was valued at the link stage by CodeWarrior. Since the linker properly put every function from those libs at odd addresses, I guessed that it should miss some information to detect that the faulty pointer was actually a function pointer.

Long story short, it turned out that the libraries were stripped, especially with the --strip-unneeded flag. I removed that flag and the linker did a perfect job!