Compile SDK11 with ARM Compiler Version 6

RE: Compile SDK11 with ARM Compiler Version 6

Emmanuel Blot — Mon, 10 Sep 2018 13:12:42 GMT

As well as SDK v15.1 / S132 v6 / LLVM v7. See https://github.com/eblot/nrf5-llvm for details

RE: Compile SDK11 with ARM Compiler Version 6

Emmanuel Blot — Thu, 31 Aug 2017 10:05:39 GMT

FWIW, it also works fine with clang-5.0.0-rc4

RE: Compile SDK11 with ARM Compiler Version 6

Emmanuel Blot — Wed, 30 Aug 2017 10:06:39 GMT

Hi,

I was sick and tired not to being able to use a modern toolchain and getting stuck with a deprecated GCC version, because of these (somewhat dodgy) SVC calls.

Unfortunately, I did not find a way to fix it with a couple of additional macros, because the "signature" parameter of the SVCALL() macro cannot be broken down (at least with the C/C++ preprocessor) into argument types and argument names. It would require the macro arguments to be rewritten with another, less readable syntax.

Anyway, it is still possible to fix the SDK to build with Clang/LLVM. At least, it now works smoothly with both a BLE 4.0 central and BLE 4.0 peripheral projects, with SDK13, S132 on nRF52 chips, with clang 4.0.1 and -O2 and -O3 optimisation level. YMMV :-)

The easiest solution I found for now is to modify (to be more precise: add some lines to) a couple of Nordic header files, i.e. the files that contain SVCALL invocations, plus the one that defines this macro (nrf_svc.h).

As hand-writing the files could be quite error-prone and because this task would have to be repeated on each SDK release, I wrote a small Python3 script to deal with it.

Building with Clang/LLVM (assuming you have downloaded or built the toolchain with support for ARM Cortex-M4 for use with nRF52) now requires to execute once the following simple steps:

Edit softdevice/s132/include/nrf_svc.h so that SVCALL declare a static inline function when Clang is in used.

--- a/components/softdevice/s132/headers/nrf_svc.h
+++ b/components/softdevice/s132/headers/nrf_svc.h
@@ -50,6 +50,9 @@
 #ifndef SVCALL
 #if defined (__CC_ARM)
 #define SVCALL(number, return_type, signature) return_type __svc(number) signature
+#elif defined(__clang__)
+#define SVCALL(number, return_type, signature) \
+   static inline return_type signature;
 #elif defined (__GNUC__)
 #ifdef __cplusplus
 #define GCC_CAST_CPP (uint16_t)

Execute the Python script on your SDK installation. It should print out (to stderr) which are the files to be patched.
```
python3.5 nrfsvc.py components/softdevice/s132
```
If everything looks ok, run the same script with the -u option switch, to update the source files. Do not execute this step if you have easy no way to revert back in case something goes wrong, you've been warned... Any SCM tool is your friend here.
```
python3.5 nrfsvc.py -u components/softdevice/s132
```
Use your favorite SCM tool to check the changes - svn diff, git diff, ... - and (re)build your project with Clang/LLVM.

Note that if you run the script on a higher directory level, you'll find a couple of files which contain non-ASCII characters, so the script will discard those files without analysing them, namely:

components/ble/common/ble_date_time.h
components/ble/common/ble_sensor_location.h
components/libraries/crypto/nrf_crypto_keys.h

It should not hurt as they do not contain SVCALL calls, and I got lazy dealing with those files (and bothering to support Python2.x) - maybe Nordic have fixed them since?

Basically, what the script does it quite simple:

it searches for all header files from the specified top-level directory
for each script that contains one or more SVCALL invocation, it parses this macro arguments, then emits a static inline function. See below for the details about these functions.
it packages in a new header file the original content of the SDK header file, and appends to this file the new inline function(s), with a couple of macros to generate the proper ARM SVC calls.
if the generation completes successfully, it swaps the original header file with the newly generated one. This last step should prevent from trashing a valid file is something goes wrong, but it should not prevent you from using a SCM tool to revert back at any time.

The emitted static inline functions are straighgforward:

Each static inline function declares which ARM registers are actually used by the supervisor call, to let the compiler know which registers are used and spilled, so it does not attempt to optimise them out. This is the root cause of the issue with the incomplete declaration made with the designed-for-GCC, provided macro.

This is at least r0 - which is used for the return code, and from none up to (r0,) r1, r2, and r3 scratch registers, i.e. for up to 4 32-bit SVC arguments. It would fail with any 64-bit argument (or return code) and would be left undetected, but AFAICT, Nordic does not use them. It also encodes in the SVC opcode which supervisor call is to be made, as with the original macro.

If you're interested in the script, the latest version it is available from here: github.com/.../nrfsvc.py

RE: Compile SDK11 with ARM Compiler Version 6

RK — Fri, 15 Jul 2016 13:37:45 GMT

... a macro which takes the current SVCALL() parameters and spits out that wrapper. That's because in order to do it, you need to know how many arguments you have and possibly have them listed out (I don't remember, it's 2 years since I did this).

It would mean adding some parameters to SVCCALL() which the other compilers don't use, but clang does, or writing a quick shim for clang. Either works.

RE: Compile SDK11 with ARM Compiler Version 6

RK — Fri, 15 Jul 2016 13:23:46 GMT

It's a bit of both. the gcc optimiser doesn't require the definitions of naked ASM functions to say they do actually use the values of all parameters, it always sets the stack up and it always takes the return value and doesn't try to optimise. That's arguably wrong because you can specify which arguments are really used and probably should. If they changed that however, it would break so much code I can't imagine they ever will. So the ASM code for the SVC calls is kind of technically wrong, but it works with GCC and is unlikely to break.

clang works rather differently, so unless you specify exactly that all the arguments to an sd_ function are used, it can, and does, optimise away the ones which it believes aren't.

It's quite easy to write an sd_ function which works perfectly well in clang, under all cases of optimisation. However what's NOT easy, is writing ..

RE: Compile SDK11 with ARM Compiler Version 6

Christopher — Fri, 15 Jul 2016 13:03:39 GMT

@hkn Thanks for your reply. I understand the reasons why this will take some time and effort.

For now GCC is the only alternative which supports some of the latest C++ features I like to work with when I develop embedded BLE applications, let's hope other compilers will support them too ;)

RE: Compile SDK11 with ARM Compiler Version 6

Håkon Alseth — Fri, 15 Jul 2016 12:46:00 GMT

I cannot comment if we're officially going to support the llvm toolchain in the future (AFAIK: It has not been discussed with management at this moment), but I am quite sure if we're going to support it in the future; it is not going to be for the next SDK release.

I can however comment on the status as-of nRF5 SDK v11:

One of the huge problems with our SDK + llvm/armclang is that the SVC handling is unreliable. This could be a problem on our side, or it can be a problem with the clang compiler. We're not sure at this moment.

For Nordic to support a new toolchain, we have to make sure that all the functionality that we provide, and use in our SDK, works with this new toolchain without compromises. At this moment; it does not do that.

Cheers, Håkon

RE: Compile SDK11 with ARM Compiler Version 6

Christopher — Fri, 15 Jul 2016 12:11:47 GMT

@Nordic Any plan to officially support the ARM Compiler Version 6 for the next SDK releases ?

RE: Compile SDK11 with ARM Compiler Version 6

RK — Fri, 10 Jun 2016 09:47:26 GMT

that would be very welcome. I have actually done this work some time ago, it was just too manual to keep up but I'm happy to share anything I still have if you want it. It's going to be a one-time pain thing to come up with a version of SVCALL which works, all my other testing with clang showed up no other issues than that although any use of __asm() probably needs auditing because inline assembler is treated quite differently from gcc, any other assembler in .s files, will be fine.

Segger Embedded Studio also has a clang option, so that's another product people are going to see a clang option and try it out.

clang is a nice compiler, it can do some very clever optimisations although it's better at making fast code than small code in my limited experience. These days with the wonderful amount of flash we get to play with it's less of an issue.

RE: Compile SDK11 with ARM Compiler Version 6

Håkon Alseth — Fri, 10 Jun 2016 09:13:55 GMT

I noticed the same thing when trying -O2 or -O3. -O1 worked fine, anything over this failed (including Os/Oz). I really like clang as a compiler and the features that it provides, and I'll try to push for a deeper investigation of the llvm toolchain internally. Since Keil v5.20/DS-5/SES all have the option to use llvm, it will become more widespread in the near future.

RE: Compile SDK11 with ARM Compiler Version 6

RK — Fri, 10 Jun 2016 08:06:16 GMT

unfortunately even optnone doesn't work in many cases, the clang optimiser is very aggressive and because there's nothing saying the arguments are used at all, even if it leaves them alone in the function itself, it often just doesn't even set them up for the call.

I've been through every single option clang has for trying to control this and not one works at high optimisation levels properly.

What's needed, unfortunately, is for the SVCALL macro to expand to have some more information, eg the count of parameters, in that way it's possible to have different stubs for different argument counts and reference that the arguments are used (and that r0 contains the return).

Arguably clang is actually right here and gcc is sort of wrong, but that doesn't really help!

RE: Compile SDK11 with ARM Compiler Version 6

Håkon Alseth — Fri, 10 Jun 2016 07:44:37 GMT

I have tested both armclang and clang-3.8, and can confirm what you state, RK. It will optimize away something (arguments in registers R0-R3 I assume?) in the SVC-calls. You can get around this with "optnone" attribute to the SVCALL macro, but that's not a proper workaround in my mind. Cheers, Håkon.

RE: Compile SDK11 with ARM Compiler Version 6

RK — Thu, 09 Jun 2016 13:34:25 GMT

is armclang related to clang, as in the LLVM compiler? If so, it's very likely not going to work at all. clang/llvm fails to generate proper softdevice calls in release mode for reasons I and others have gone into at length on other threads. You can't currently use clang to compile so if armclang is based on LLVM, give up.

RE: Compile SDK11 with ARM Compiler Version 6

Christopher — Thu, 09 Jun 2016 13:28:49 GMT

It seems to be quite impossible to patch every files of the SDK by myself to add the new compiler abstraction...