Fix compilation for ARM Cortex-M3

[salkinium]

I'm currently integrating CrashCatcher and CrashDebug into modm and I'm compiling this for the ARMv6-M, ARMv7-M and ARMv7E-M architectures.

The ARMv7-M Thumb2 instruction set does not have any FPU instructions so the assembler is unable to compile for ARM Cortex-M3 devices.

I used the predefined architecture macros from GCC to disable the FPU registers, but it's an ugly solution. Is there a reason why you're dynamically checking for isARMv6MDevice()? This is definitely known at compile time and you even provide different static libraries for this anyways.

cc @adamgreen

[adamgreen]

Thanks for the PR. This change should only be required if you are building the sources using your own makefile or equivalent since the CrashCatcher makefile builds a armv7 library that works for both devices with and without FPU support.

Is there a reason why you're dynamically checking for isARMv6MDevice()?

This was done to reduce the differences between builds of the C code on different platforms so that when built on the host device for unit testing, the code would be as similar as possible to what runs on Cortex-M microcontrollers. As it is written currently, the unit tests can externally force the C code under test to think it is running on v6 or v7 devices and test both code paths from a single test binary.

[salkinium]

a armv7 library that works for both devices with and without FPU support.

Ah, of course. You can use the M4 binary on M3 too, since it checks at runtime for FPU support. Neat! Of course once the GCC ARMv7 backend gets cool and uses DSP instructions for optimizing it's C code, this stops working. But GCC is not going to get cool anytime soon 🤪.

As it is written currently, the unit tests can externally force the C code under test to think it is running on v6 or v7 devices

That makes a lot of sense, completely forgot about how to test this!