- This topic has 3 replies, 2 voices, and was last updated 4 years, 9 months ago by
.
-
Posts
-
Hi,
I recently upgraded to (actually a parallel install of) Visual Studio 2015, and reinstalled the latest version of VisualGDB for STM32/ARM development (I’ve been a licensee for about 3 years now).
If I simply rebuild my project using the existing makefile then all is well, output is exactly the same as with previous versions – as you’d expect given the same build tools.
However, if I use the “Convert to MSBuild” project feature then assembler (.s) source modules are ignored when using “Build all”, plus the generated rom file is garbage – it seems to consist of nothing but a stub, using 28 bytes of RAM and 168 bytes of flash.
On the bright side, I am able to compile individual source modules from the editor using Build|Compile, which is a feature that doesn’t work when using makefiles. It’s something I’d like to keep!
Any idea what the problem is? Would it be better to create an MSBuild project from scratch?
In case it’s relevant, I also noticed that the folder structure seemed to change, i.e. a VisualGDB folder is added to the project containing Debug and Release subfolders. In the past there was a “VisualGDBCache” folder containing $(ProjectName)-Debug and $(ProjectName)-Release subfolders. Also the garbage executable seems to be in a secondary VisualGDB folder added to the solution folder instead of the project folder.
No problem, we can help you get it to work.
The “Convert to MSBuild” command will import the common parameters (e.g. include directories and macro names) from the Makefiles and copy them to the MSBuild project properties, however it would not pick up custom Makefile rules and other adjustments. This should work for most of the projects, but may indeed require minor manual adjustments to reflect the settings that were not automatically converted.
Based on what you have described, the assembly files did not get the correct item type and hence are being ignored. Please try selecting them in Solution Explorer, right-click and select Properties (for those items) and set the Item Type on the General page to C/C++ compiler. Please also ensure that they are not marked as “Excluded from build”.
If this doesn’t help, please let us know and we will provide more detailed instructions.
Thank you, that seems to have worked perfectly. As a bonus the “in editor” Debug|Compile feature now works for assembler modules too, which I didn’t realize could be hoped for.
The only minor mystery was why the code built and linked with no problem, other than being suspiciously small! 🙂 In hindsight I’m going to guess that since my startup code (with reset address) was in an assembly module, which was ignored and possibly replaced by some kind of default, that the rest of my program was unreferenced and removed by the linker.
Thanks again.
No problem, we can explain what happened.
The linker automatically discards the symbols that are not referenced by any other symbols in the project, starting at the entry point. E.g. if your main file contains functions func1() and func2(), but main() only calls func1(), the body of func2() will be removed from the linked binary in order to save space. However, it the entry point itself is eliminated, every function in the project will be considered unused (unless explicitly marked with special GNU attributes or linker script directives) and hence the linking will produce a nearly empty result.
- You must be logged in to reply to this topic.