V5.4R3 CFLAGS ignored, random values

[ChangedDaily]

Hi,

I recently updated VisualGDB to 5.4R3. Today I opened a project that I have worked on for over a year. I was very surprised when I compiled after changing a couple of lines in a file that compilation failed due to some other errors. On further investigation it seems that the flags used for compilation seem quite random and don’t match what I have in the properties page. For example, I have -O2 in all CFLAGS, ASFLAGS and when that failed Common flags but the command line still gets -O0.

I am going to try and roll back to a previous version of VisualGDB in the hope that will fix this. Hopefully it won’t get worse.

 

 

[support]

Sorry about that. This is strange, as we have not changed the logic related to the CFLAGS in v5.4R3, however it might be a side effect of some other change.

We can help you resolve this if you could let us know the project type (Embedded/Remote Linux/Cross-compiled Linux), the build system (Make/CMake/MSBuild) and also give a specific example of the command line you get, command line you expect and the entire .mak/.props/.vcxproj file where the flags are defined (if you are not sure, we can provide more details once we know the project type).

[ChangedDaily]

Hi, I have rolled back to V5.3R8 on my backup PC and that is working as expected. Answers to easy questions:

Embedded

MSBuild

Actual output with 5.4R3:

COLLECT_GCC_OPTIONS=’-mthumb’ ‘-I’ ‘STLib/inc’ ‘-ggdb’ ‘-O0’ ‘-D’ ‘RELEASEVERSION=5503’ ‘-D’ ‘TESTDEFS_DEBUG_UDP_CONTENTS’ ‘-D’
‘CONFIGNAME=”Code_GSM”‘ ‘-D’ ‘USE_DEV_SERVER’ ‘-D’ ‘RELEASEVERSION=5503’ ‘-D’ ‘DEBUG=1’ ‘-ffunction-sections’ ‘-fdata-sections’
‘-Wpedantic’ ‘-pedantic-errors’ ‘-Wextra’ ‘-Wconversion’ ‘-c’ ‘-march=armv7-m’ ‘-v’ ‘-c’ ‘-o’

CFLAGS are set as follows: -O2 -pedantic -pedantic-errors -w -Wextra -Wconversion -c -xc -mthumb -march=armv7-m -ffunction-sections

I’m not attaching screenshot as my previous attempts at that have failed.

With 5.3R8:

C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin\arm-none-eabi-gcc.exe -ISTLib/inc -ggdb -w -Werror -O2
-DRELEASEVERSION=5503 ‘-DCONFIGNAME=”Code_GSM”‘ -DUSE_DEV_SERVER -DDEBUG=1 -ffunction-sections -fdata-sections -pedantic
-pedantic-errors -Wextra -Wconversion -c -xc -mthumb -march=armv7-m

 

Note the main issues here are that O2 has changed to O0 and the -w doesn’t appear at all with 5.4R3.

I’ll get further info later.

 

• This reply was modified 5 years, 1 month ago by ChangedDaily.

[support]

Thanks for the update. This is likely a side effect of changing the order in which the MCU-specific property sheet is applied. We have changed the order so that the values from the VS Project Properties would override the default values derived from BSP.

Most likely you have manually defined some of the flags in a way that we did not expect and hence they are getting overridden as well.

If you could post here (or send us via the support form) the mcu.props, mcu.xml and the .vcxproj file, we should be able to reproduce this quickly and make the necessary adjustments on our side.

[ChangedDaily]

Hi again,

I am just getting back to a different project and it occurred to me that the past 2 days I have spent on that project trying to get to the bottom of an issue may be due to the -O2 flag! I actually only got the code working by going to GNU build system. I knew the code had to be built with -O2 flag but had checked numerous times that it was set so I was investigating all sorts of other possibilities. With the GNU build on that project I was able to switch -O2 on and off to demonstrate to my satisfaction the code worked/didn’t work according to the flag.

I am going to copy that project to my backup PC to see if it will work with MSBuild on VGDB 5.3R8.

Well, actually I just checked on that project with –verbose and it is being compiled with -O0 instead of O2. That will be the cause of my problems there as well.

 

• This reply was modified 5 years, 1 month ago by ChangedDaily.

[support]

Thanks for the update. We understand your frustration with this and we do apologize for the inconvenience this have caused, however since there are many different ways in which the VisualGDB projects could specify various build flags, it is hard for us to provide a hotfix for this without either seeing the original .props/.xml/.vcxproj files, or getting the exact repro steps that we could run on our side in order to reproduce the behavior. The good news is that once we can reproduce it on our side, we should be able to fix in about 1 day.

[ChangedDaily]

BTW – all projects are standalone. I create the projects using the wizard and specify flags manually.

 

PS I have also seen some issues where files organised by filters seem to move out from the filters back to the root. That seems to happen when I add files to the project folder. That’s another story for later though.

[ChangedDaily]

Further testing – going to the “standard” properties page, optimisation was set to O0. Changed that to O2 and it changes. So it seems that setting now overrides the setting in VGDB properties page.

Just based on very quick test.

 

[support]

Thanks for the update, this makes sense. If you had previously selected -O0 in the regular VS Project Properties and -O2 in the stand-alone project properties, indeed the behavior would change in v5.4R3.

We had to change this because the previous logic did not provide an easy way to override the default settings provided by VisualGDB for regular (non-standalone) projects.

Generally, we would advise using the stand-alone project properties for device-specific flags (e.g. specific preprocessor macros, FPU type, etc) and the VS Project Properties pages for general C/C++ settings (optimization level, warnings, debug information). If this is not possible due to any reason, please let us know and we will help you find a workaround.

[ChangedDaily]

Hi,

I’m not sure there’s a good answer to this. The ability to assign different values to the same setting in two different places is really bad.

What concerns me is not knowing which compiler or linker settings that I make in the VGDB properties page will be used and which will be overridden. I don’t think it’s feasible to remember or even have a checklist of which ones are duplicated.

Perhaps the best solution would be for VGDB to warn if any settings are detected in the VGDB properties page that may be set elsewhere or indeed have different values set elsewhere.

Patrick

 

 

[support]

Sorry about that. For regular (non-stand-alone) projects there is no redundancy between different types of settings, as we specifically design our BSPs so that the settings specified there do not conflict with the regular VS project properties. The stand-alone projects do give you full control over all flags specified on the BSP level, however it indeed creates a possibility for conflicts.

That said, you don’t need to remember a checklist of flags – simply check VS Project Properties (not VisualGDB Project Properties) -> Configuration Properties -> C/C++ -> Command Line and you will see a detailed list of flags derived from the VS project properties (that will normally override any similar flags from the BSP).

Unfortunately, the exact names of conflicting settings are slightly different between the GCC versions (e.g. newer versions introduce more optimization levels or debug format levels), so reliably checking for all possible conflicts would be a relatively complex and error-prone task. As the scenario you described is relatively rare, we are happy to update the documentation and help you understand the exact logic behind this, however we would like to avoid introducing complex error-prone logic for handling it fully automatically, sorry.

[ChangedDaily]

Hi,

 

This has now become unacceptable. Every previously created project I open (all are standalone) now fails to build. I updated my subscription and Visual GDB in order to make use of the new features for ESP IDF projects (which I ended up not using) and that has broken everything else I have worked on in the past two years. I’ll bet there’s loads of others out there with the same problem but they just haven’t realised yet.

The only solution I can see is to roll back Visual GDB and accept that I won’t ever be able to use newer versions of GDB or go through every project I have changing the settings, compiling, checking checksums, creating new version control entries…

Hmmm

[support]

Sorry about that. There is no need to roll back – we can add a setting to VisualGDB that will allow switching between the old and the new behavior, although the redundancy between the optimization setting in the VS properties and the manually specified flag in the stand-alone project properties may cause further disturbances in the future.

We can also create a small tool that will check the stand-alone projects for the optimization flag and would move it to the correct VS-level property, eliminating the redundancy. Depending on how your projects are structured, running a single tool followed by a command-line build could be viable. If not, we can add the setting described above.

[ChangedDaily]

Hi,

 

Thanks for proposing some fix for this. It would be quite acceptable if all I have to do is select a checkbox and the settings I make in VGDB are then applied as previously. Or, would it make sense for the functionality of such a feature be to set the compiler command line options as per the CFLAGS in the VGDB page and ignore any settings in VS?

 

[support]

No problem, we have added a registry setting that fully restores the old behavior for all of the projects on a specific user account.

Please try this build: VisualGDB-5.4.105.3118.msi

Then, set the HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings\BSPFlagsOverridePerConfigurationFlags value in registry (REG_DWORD) to 1, or simply use the attached .reg file.

Please note that both the original change and this fix only affect the logic for generating the mcu.props file, that happens each time you change a setting on the first page of VisualGDB Project Properties and click “Apply”. Hence in order to restore the old behavior, please edit any setting on that page after updating the registry. You can verify that the mcu.props overrides the settings from the .vcxproj file by checking the “Condition” attribute, e.g.:

 <ClCompile>
<Optimization Condition="true">O3</Optimization>
</ClCompile>

The projects that were created with the old VisualGDB version and were never edited with v5.4 do not need to be updated as their mcu.props file still uses the old syntax.

Let us know if you have any further questions/suggestions and we will be happy to help.

Attachments:

You must be logged in to view attached files.

[Author]

Posts