[support]

Sorry, it is not supported. We might be able to add it in one of the next versions of VisualGDB but it’s hard to give any estimates at this point as it would require non-trivial changes on our side.

[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.

[support]

Thanks for pointing this out. It turned out to be our bug – in the recent V5.4R3 update we optimized the initialization logic of VisualGDB: instead of loading during Visual Studio startup, it would only get initialized once a VisualGDB-based project is loaded, or any of the VisualGDB-related commands is used. It turns out, when loading the multi-project solutions via command line, Visual Studio sent some of the project load events in a slightly different order, that caused VisualGDB to miss some of them.

We have fully fixed the issue in the following build: VisualGDB-5.4.103.3022.msi

Sorry for the inconvenience and thanks for providing sufficient details for us to reproduce the issue.

[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.

[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.

[support]

Good to know you found the root cause. If you encounter further problems, please don’t hesitate to create another thread.

[support]

Thanks for the update. If you encounter any further issues, please do not hesitate to get back to us.

[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).

[support]

Sorry about that. We have already fixed it in this build [VisualGDB-5.4.103.3020.msi] and will release R4 including the fix in the next few days.

[support]

Hi,

Most likely, the original project contains some special settings that were not automatically imported.

The easiest way is to narrow this down to a specific source file and then compare the build command lines used by the Keil IDE and by VisualGDB. You can find the VisualGDB’s command lines in the .rsp files inside <project directory>\VisualGDB\Debug. The command lines from the Keil IDE can be found by enabling the .bat file generation and looking through the generated file (it will use the –Via <filename> syntax where <filename> will correspond to the response files generated by Keil).

Once you find out a specific command-line argument, we can help you locate the corresponding VisualGDB setting.

[support]

Sorry for the delay, we had to do some investigation on our side in order to come up with possible fixes.

VisualGDB cleans the remotely built projects by removing the entire directory with the temporary make file (.msbuild-mak extension). This is done instead of precise file-by-file cleaning in order to reduce the delays due to network latency.

Hence, the easiest way to fix this would be to ensure that each project has a separate intermediate directory (set via the $(IntDir) variable). If this doesn’t help, we could add a setting for running a custom command line instead of deleting the entire directory, so you could fine-tune the exact list of files you would like to delete via the rebuild/clean commands.

[support]

No worries, we understand that reloading the projects manually each time is very inconvenient. We only suggested doing this to narrow down the problem to a specific project/setting.

The “???” display for non-VisualGDB projects is also by design.

Please try opening View->Clang IntelliSense Diagnostics Console->Log when the solution is not open, clearing it and loading the solution. Then check the log for red error lines. If attaching to one of the projects triggers an unexpected exception, this might prevent VisualGDB from attaching to further projects during the same operation. We should be able to fix this once we know more details.

If this doesn’t help, please try creating a copy of the .sln file, then remove half of the projects from it and load the new solution (ensure you delete the .vs folder to clear out any caches). Then repeat it until you find a minimal combination of projects that does not load properly when opening the solution and check if there is anything different about the project triggering the problem.

[support]

Thanks for sharing the details – it helped pinpoint the problem on our side. We have added a check for this case and an option to clean the projects via “make clean” in this build: VisualGDB-5.4.103.3020.msi

[support]

@grindstaffp, thanks for sharing the specific steps that helped us reproduce the issue on our side.

Indeed, this was a glitch caused by the new background loading mechanism introduced in R3. Please try this build: VisualGDB-5.4.103.3020.msi

[support]

GDB should not normally interfere with it, however you can quickly check whether your device supports it by inserting some code with this instruction into a basic LEDBlink program using some inline assembly and then using Debug->Program and start without debugging. If this stops the LED from blinking, your device may not support this instruction.

[Author]

Posts