My embedded applications are implemented mostly in C, a few in C/C++. But all of them have one or few assembly files included too: Assembly programming is the needed to do low-level things so it is a natural part of a true embedded application. For example I use often an assembly file for the application startup code.
I have run into a nasty Eclipse CDT issue which deals with assembly files projects. Here is a quizz for you: can you spot the problem in my project below?
Startup Assembly Code
Found the problem? Well, the thing is that this project will compile, assemle and link just fine. But it won’t actually use my code in startup.s!
This can be easily verified with adding some garbage into startup.s: that file will not be assembled and won’t be part of the build. Similar as it would be a text file: it is simply not included as source file into the CDT build!
So what is wrong with it? It is the extension of the file: it is *.s (lower case ‘S’) and not *.S (upper case ‘S’) :-(.
The issue is that in CDT (at least in 8.6 which I’m using here), only *.S is recognized as assembly file extension. This is configured by Window > Preferences > C/C++ > File Types:
S as Assembly File Extension.S as Assembly File Extension
But hey, there is a way to add a new extension:
Adding new extension
But this does not work :-(:
Error Setting Assembly File Extension
Well, that error message somehow does not make much sense, as there is no *.s association set.
The above setting is for the workspace. As for many things in Eclipse, it is possible to use per-project settings. And indeed, in the project settings I can add *.s as assembly source file:
File Types in Project Settings
With *.s added, it now treats both *.S and *.s as assembly source files :-).
Summary
Because of an issue in Eclipse CDT (see links below), only *.S files are recognized as assembly files in the workspace settings. So I have to make sure that all my assembly files are using upper case *.S extensions, otherwise they are not treated as assembly files in Eclipse CDT. The only way to use *.s assembly files is to add a custom file type in the project settings.
Happy Assembling 🙂
Links
- Discussion of the *.s issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=278026 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=105022
MCU on Eclipse 
Yes – this is an annoying “feature” of CDT since as long as I can remember. Be aware though that traditionally *.S gets preprocessed and then assembled but *.s does not get preprocessed and just gets assembled. I’m not sure if CDT adheres to this convention?
This may or may not be significant depending on the content of your files. But if you have a *.s file with preprocessor directives then I presume that it will just generate an error when the assembler is called assuming that CDT does not preprocess such files first.
Another way to avoid all this hassle with *.S v *.s etc. might be to name your assembly files *.asm instead which get preprocessed and then assembled. 🙂
LikeLike
I did not know about the difference of preprocessing, thanks for that hint. Usually I stick to *.S because that’s easier and I don’t have to add custom file extension handling. Good point about using .asm instead, I have to keep that in mind for my new projects, thank you!
LikeLike
We faced this problem when we added support for importing STM32 and TrueStudio projects; a lot of the STM32 online example projects use lower case s assembly file extension. This is fixed in our latest version of DRT; both upper and lower case s are supported.
LikeLike
Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 10 – Assembly Stepping | MCU on Eclipse