thumb misalignment? [was: memcpy oddness]

morgan · ‎2016-08-02

Posted on August 03, 2016 at 05:47

Hi Guys,

I've recently started working with the STM32F0 series of microcontrollers, took a while to get a fully functional build chain up and running, but now everything looks good on that front. I've run into an oddball issue with memcpy, initially I thought it was an issue with one of the libraries I'm importing, but I've since dropped that and I'm seeing the issue in user code. It appears that the __memcpy_from_thumb stub is misaligned somehow, I've disassembled the code in IDA and it all looks fine, but when I step through it in GDB things look very weird. Segment in question in IDA;

.text:08002640 CODE16
.text:08002640
.text:08002640 ; =============== S U B R O U T I N E =======================================
.text:08002640
.text:08002640 ; Attributes: thunk
.text:08002640
.text:08002640 __memcpy_from_thumb ; CODE XREF: wc_Md5Update+3C&#24;p
.text:08002640 ; wc_Md5Final+AC&#24;p ...
.text:08002640 BX PC
.text:08002640 ; ---------------------------------------------------------------------------
.text:08002642 ALIGN 4
.text:08002644 CODE32
.text:08002644
.text:08002644 loc_8002644 ; CODE XREF: __memcpy_from_thumb&#24;j
.text:08002644 B memcpy
.text:08002644 ; End of function __memcpy_from_thumb
.text:08002644

Everything looks good, drilling through to memcpy leads me to something that looks very much like a memcpy function, so it looks like IDA is doing the business. However, when I load the code to my target (STM32F051R8 on the STM32F0DISCOVERY) and step through it in GDB I get the following;

0x8002640 <
__memcpy_from_thumb
> bx pc 
0x8002642 <
__memcpy_from_thumb
+2> nop ; (mov r8, r8)
0x8002644 <
__memcpy_from_thumb
+4> ; <
UNDEFINED
> instruction: 0xff81eaff

Stepping through the code lands me in the HardFault handler. This looks for all the world like it's misaligned but I've no idea where to start with troubleshooting this issue. Any assistance would be greatly appreciated. Thanks, -J

morgan · ‎2016-08-02

Posted on August 03, 2016 at 07:01

Looks like I have the same issue with anything from thumb.

____aeabi_uidiv_from_thumb

____aeabi_uidivmod_from_thumb

Both show the issue, which would suggest there's something wrong in my toolchain/linking, once again, any suggestions would be greatly appreciated.

AvaTar · ‎2016-08-03

Posted on August 03, 2016 at 11:03

> Both show the issue, which would suggest there's something wrong in my toolchain/linking, ...

I agree. Don't know your toolchain/IDE, but the name(s) ''

xxx_from_thumb

'' implies ''to ARM'', at least for me. And as a matter of fact, ARM instructions are not supported by any Cortex M.

Pulled the wrong libs ?

morgan · ‎2016-08-05

Posted on August 05, 2016 at 09:20

Thanks for your response.

I'm using a GCC based toolchain, particularly arm-none-eabi-gcc from Debian 8.2.

It looks like I'm missing something altogether from my linking, I've turned up a project libaeabi-cortexm0 which provides a lot of the missing functionality but I'm still running into gaps, the latest is it's looking for i2d which isn't present in libaeabi-cortexm0.

It seems that the newlib is being implicitly pulled into my build but it appears that it's been built for ARM not thumb, I'm passing -mthumb to gcc, so my code is at least being generated in thumb not ARM, but obviously if the linker is pulling in symbols from a library in ARM that ain't going to work...

AvaTar · ‎2016-08-05

Posted on August 05, 2016 at 11:34

I'm not clear about your whole environment, and how your project had been setup.

IDEs (like uVision/EW_ARM, etc.) have ''wizards'' that let you easily setup projects, and will pick the right libs (and sort of libs) for the MCU chosen.

Changing the MCU (M0<-->M3<-->M4) of such a project often fails, exactly because of linker issues. The M0 and M0+ have just a subset of Thumb2 instructions implemented, and will most probably hardfault on code/libs built for M3/M4.

I use to create a fresh project for the new MCU and drop the sources in. Hacking opaque project settings (like Eclipse) seems favorable only at first glance.

Not sure if that applies to your issue, but the ''spreading'' of objects is, beside of standard libs like libc.a and libm.a, is highly toolchain specific.

morgan · ‎2016-08-07

Posted on August 07, 2016 at 14:42

The project is based on a GCC toolchain, using hand written linker scripts and a hand written Makefile against the Standard Peripherals Library for my micro. I'm not using an IDE.

I resolved the issue in the end, turns out you need to pass -mthumb and -mcpu=cortex-m0 to the linker as well as the compiler, otherwise it links the wrong libs in, just -mthumb is not sufficient for some unknown reason, possibly a bug in GCC.