Forum Replies Created
-
Posts
-
Thanks for the update. If you encounter any further issues, please do not hesitate to get back to us.
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).
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.
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.
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.
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.
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
@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
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.
The IT instruction might not be supported by your device. Please double-check its documentation to be 100% sure.
No problem. The IntDir might have been set in a different order then (i.e. before VisualGDB computes the paths of some intermediate files). Either way, we have added the checks for this case in the new build, so unless you encounter further problems, the project should be good to go.
Thanks for the project file. We have tried reproducing this on our side, however could not get the behavior you described, so we added more logging to the related logic in VisualGDB.
Please try this build: VisualGDB-5.4.103.3019.msi
Please open your project, confirm that the menus are still not shown, then click Help->About VisualGDB to force VisualGDB to load. Once it is loaded, open View->Other Windows->VisualGDB Diagnostics Console and enable the logging. The console will already have the output from the project load hook. Please share it here and we will be able to see what is going on.
Thanks, looks like your project did not have the $(IntDir) variable set and that triggered an unexpected path format inside VisualGDB. We have added a check for it in the following build: VisualGDB-5.4.103.3019.msi
Hi,
Most likely the library mentioned in the error message is either corrupt, or is not installed in the correct path. Please try ignoring the error and proceed to debugging the project.
If the error reoccurs, please try using the View->Other Windows->VisualGDB Diagnostics Console to see the exact command line used by VisualGDB to start debugging and then try running it manually via SSH. If the problem can be reproduced, please double-check LD_LIBRARY_PATH variable and the actual .so files present in the path directories.
Hi,
The previous versions of VisualGDB would still try to guess the IntelliSense parameters for the files that are not directly compiled, but would indeed not show the warning.
Either way, we can help you pinpoint this. Please identify a specific source file that triggers the problem and take a note of its full path (right-click on the document tab header and select “copy full path”). Then open View->Clang IntelliSense Diagnostics Console, switch it to the Project Structure view and check if the file is listed there with the exactly the same path. If it is not and you are not sure why, please share more details about your project (project type, what files from the project are listed, what are not, etc.).
Please also try reducing the solution to just 1 project (ensure you reload it afterwards) – it should make diagnostics easier.
If the problem only happens for header files, please let us know and we will share updated instructions.
