Forum Replies Created
-
Posts
-
If the ls/stat commands produce output that looks valid, but doesn’t match the actual state of the file system, it could indicate a filesystem corruption or some other strange bug.
In generally, VisualGDB needs a reliable way to find out the name of the file that was created in response to the “dump” command. Our best advice would be to experiment with different modes of ls, stat and also run the dump command multiple times to understand why they don’t work on that target. In generally, the output from the file listing command after running the dump command should contain exactly 1 more entry starting with “callgrind.out”.
Hi,
Building MSBuild-based VisualGDB projects does require VisualGDB, since it provides the actual build rules for them (see this page). However, you can easily dump the build steps for your project into a batch file (see this page), check it into the source control, and run it on the build server. You will need to patch the batch file and the .rsp files it to replace the absolute paths with proper variables, but it should be a good starting point anyway.
If generating the .bat files is not an option, you would nee to make sure that the build server has the same Visual Studio configuration as the development machine (including MSBuild toolsets, etc.). You may also be able to get it working with a smaller MSBuild installation, although you would need to manually track down the error messages (they usually show the .props/.targets file where the error happens) and adjust the project accordingly (e.g. define some variables that the stand-alone installation expects). Generally, this is something to do at your own risk – using the batch files or getting a full VS installation should work much more reliably.
Just wanted to clarify that if any of our users are interested in taking this project, please feel free to contact @GeneM.
We are currently working on a few VisualGDB customizations requested by our large customers and have no resources to take it in the near timeframe.
This error happens with VisualGDB requests Valgrind to dump the current information gathered by the profiler into a dump file. Normally, it would create a new dump file in the Valgrind session directory (/tmp/2e48884f-d532-4289-9e0b-2e1378af5121 in this case), however due to some reason, Valgrind does not create it in this case, or VisualGDB fails to locate it.
In order to troubleshoot it further, please try following the steps below:
- Enable View->Other Windows->VisualGDB Diagnostics Console.
- Start a profiling session with debugging and wait for it to trigger on a breakpoint.
- Locate the valgrind launch command in the diagnostics console and find out session directory from the –vgdb-prefix switch.
- Check the contents on the session directory manually.
- Try running the “monitor dump” command in the GDB Session window.
- Check if this created any new files in the session directory.
If Valgrind did not create any new dump files, it could be a bug of Valgrind. Trying other configuration options, or a newer Valgrind version might solve the problem.
If the new dump file was created, the remote system might be missing the ‘ls’ or ‘stat’ commands used by VisualGDB to query the file list. You can locate the exact command lines used by VisualGDB (e.g. cd “/tmp/34f1e35f-a7e2-4b00-b34c-24659c90a8f5” && ls -1A | xargs -d “\n” stat -c “StatEntryL:|%N|%Y|%d|%s|%f” .) in VisualGDB Diagnostics Console and try running them manually to see if they work on the target. If you get any errors from running that command line, please let us know and we will investigate it further.
Hi,
Sorry, this looks like a bug of the gcc compiler and not a VisualGDB-specific issue.
Our best advice would be to try reproducing it in a command-line build (if you are using MSBuild, you can configure it via VS Project Properties to create a .bat file with all build commands) and try posting in the GCC mailing list.
Another option would be to try using the Keil or IAR compiler instead of GCC. VisualGDB supports both of them and they generally provide a better optimization than GCC, and come with their own support.
Sorry, this is only officially supported for the ARM devices.
You could try extracting the heap parsing logic from our FreeRTOS plugin and creating a custom expression visualizer based on it, but it will involve non-trivial coding.
Thanks for renewing your support.
We indeed no longer include the GNU Make executable with our toolchains. Instead, we have switched them to using make.exe from the VisualGDB directory. This should automatically apply to newly created projects. However, if you have created your project with an older version of toolchain, it would need to be updated manually. If this is the case, please try setting the Make path in VisualGDB Project Properties -> Make Build Settings to $(VISUALGDB_DIR)\make.exe.
You can also simply copy make.exe from the VisualGDB directory to the toolchain directory if you do not want to edit the project file.
No worries. Just please be aware that the 50% renewal discount we give for VisualGDB always extends the previous expiration date by 1 year, regardless of the actual date of purchase. So unless you have a very old license that doesn’t qualify for the regular renewal discount anymore, there is no advantage of delaying the update.
Also Microsoft has recently switched to faster release of VS updates that often break backward compatibility or introduce new issues (e.g. VS16.10 broke IntelliSense interface compatibility with older VS2019 builds). We usually release hotfixes for these issues very fast, but they do require an active license.
Good to know it works. The new suggestion GUI relies on the new and somewhat underdocumented APIs from Visual Studio, so it may indeed have unexpected side effects that were not found by our internal tests. We will definitely appreciate any feedback on it and will be happy to fix any issues that we can reproduce.
Edit: we just caught an issue that was sometimes causing the “waiting for the editor operation to complete” window to appear. We have fixed it in this build: VisualGDB-5.6.1.4150.msi.
Hi,
This is correct. The newer versions of OpenOCD, BSPs and other packages often rely on the new features introduced in the recent VisualGDB versions, and will not work with the older VisualGDB releases.
If you would like to stay up-to-date with the latest tools and packages, we recommend using the latest version of VisualGDB as well.
Hi,
Sorry about that. Please try this build: VisualGDB-5.6.1.4149.msi
Hi,
The Live Variables (renamed to Live Watch in v5.4) and other live functionality only works for targets that support reading the memory without stopping the CPU. This includes most new ARM devices and RISC-V devices, but not ESP32 or ESP8266.
Hi,
Thanks for reporting this. We have successfully reproduced the problem and fixed it in the following build: VisualGDB-5.6.1.4144.msi
If you encounter further issues, please feel free to let us know more details, and we will be happy resolve them.
Hi,
No problem. First of all, please note that this is outside our regular product support scope, as it is a general C/C++ programming question, rather than a VisualGDB-specific issue.
However, as we have helped you port the project from Keil to GCC via our consulting service, we will gladly explain this as a part of the porting support.
The __DATE__ macro is only expanded by the compiler when the corresponding source file is physically compiled. E.g., if none of the project files have changed since the last build, the project will be considered up-to-date, and the old binary with the old __DATE__ value will be preserved. This also works on the file level. E.g. if main.c contains a printf(__DATE__), or a similar statement, modifying auxiliary.c will build a newer firmware version, but it will still show the old date, because the function checking it was not rebuilt this time.
If you would like to ensure that the __DATE__ value is always up-to-date, please consider making a dedicated function that checks and returns it in one of the .c files (not headers that are used by multiple sources) and add a custom pre-build step that will reset the timestamp on that .c file (e.g. using the touch command from MinGW or any other similar tool).
You can also simply do a full rebuild (Build->Rebuild All). This will make sure all files are rebuilt, so the old date will not be cached anywhere.
No problem. We were delaying the update to Ninja 1.10, as it caused issues with NRFConnect projects. However, the latest NRFConnect release has solved them. Please try this build: VisualGDB-5.6.1.4142.msi
We will also include the latest Ninja version in the upcoming VisualGDB 5.6 Beta 2.
