Forum Replies Created
-
Posts
-
Hi,
It is totally possible that older versions of CrossWorks would handle things differently. This is exactly why we published the sources of our importing plugin.
There is no special tutorial for the plugin, you can simply open its solution in Visual Studio, build it and replace the original plugin in the VisualGDB directory.
As for the build flags, they are likely stored in way that the importing plugin cannot easily deduce (or is different from the CrossWorks version we tested). Specifying them manually, or patching the plugin if you would like to import multiple projects, should work just fine.
Thanks for renewing your support.
Our CrossWorks project importer uses the .ind files to determine the full list of implicit sources (coming from CrossWorks packages) used to build the project. In our experiments, this was the only way to locate these implicit dependencies that are otherwise not referenced anywhere.
You can actually find the logic used by the CrossWorks importer here. We intentionally publish the sources for all project importer plugins, so that our users can tweak them to their needs.
In this case, you can simply ignore the warning about the .ind files and proceed with importing the project anyway. If the resulting project won’t build due to missing symbols, you can try examining the map file produced by CrossWorks, or searching the object files in its build directory for the definitions of these symbols, and manually adding the corresponding files to the VisualGDB project.
In general, when it comes to importing projects from other tools, VisualGDB can automatically parse common settings (list of source files, include directories, preprocessor macros, device type, etc.), but indeed, it won’t translate every possible setting from the original project file. This speeds up the importing process compared to creating a new project and adding everything there manually, but indeed requires minor adjustments to accommodate the settings that could not be translated automatically.
Hi,
This looks like something specific to your target (e.g. some headers got moved or edited).
The easiest way to fix it would be to delete the cached include directories for that target (via VisualGDB Project Properties or by deleting %LOCALAPPDATA%\VisualGDB\RemoteSourceCache\<hostname>) and rebuilding the MSBuild toolchain profile (VisualGDB Project Properties -> MSBuild -> Regenerate MSBuild Files).
If it doesn’t help, please try locating the %LOCALAPPDATA%\VisualGDB\ToolchainProfiles\<hostname>\com.sysprogs.toolchain.default-gcc-\IntelliSense.props file. It contains the include directories and preprocessor macros used to configure IntelliSense based on various options (e.g. language standard). You can simply add the /usr/include/c++/10/tr1 directory to the AdditionalIncludeDirectories element (or even make it conditional on CPPLanguageStandard, similar to PreprocessorDefinitions). Editing the file and reopening the solution will make the directory visible to IntelliSense without affecting the build.
Hi,
No problem, we will try to help. The delay could be caused by 2 independent issues:
- Reading/parsing the symbols from the ELF file
- Physically reading the memory contents from the device
It is difficult to suggest anything more specific without seeing which parts of the GUI get delayed and which modes you are using. If you could create a short video demonstrating the problem, we might be able to suggest some workarounds.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.
You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.
You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.
Please note that VisualGDB is a productivity tool for software developers. It can make developers more productive by providing convenient GUI for common time-consuming tasks, and integrating various external tools into Visual Studio, so that they are always a few mouse clicks away.
We are able to offer VisualGDB at affordable price, because we focus on developing and supporting functionality that works the same way for multiple users, hence the development and testing effort is reused between multiple license holders.
We also receive a huge amount of inquiries asking to fix a specific broken project, help make the correct design choice, explain how a specific C++ feature works, or assist porting a library to a different platform. These inquiries require considerable effort to research and communicate the best solution. They do not scale between multiple users. I.e. helping one user solve this type of problem will not automatically help other users. It also does not help the same user avoid the same type of problem in the future. Hence, we are not able to address them within our regular support. If we included this type of help in our support, we would simply not have sufficient resources to provide it at the current license prices, or to allocate any resources to VisualGDB development.
We are happy to offer project-specific help via our consulting service per Zoom, TeamViewer or any other screen sharing service of your choice. We charge a fixed hourly rate for these sessions (billed in 1/2-hour increments), and are happy to solve any problems our users encounter. The rate includes a detailed follow-up email at the end of the session, that includes an overview of the used techniques and a summary of solved problems and future recommendations. Please contact our sales if you need more information about it.
Alternatively, please consider browsing our documentation and tutorials. Our documentation lists most VisualGDB settings, and the tutorials show how to use VisualGDB for in many real-world scenarios. Our technical support is limited to issues in VisualGDB itself, that can be reproduced from scratch per our problem reporting guidelines (i.e. do not depend on external projects that can potentially contain errors).
If you believe parts of VisualGDB are not working correctly (e.g. C library cannot be changed), please provide complete and detailed steps to reproduce the issue as described below:
- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
No problem, we can clarify.
VisualGDB normally manages toolchains by keeping a list of Toolchain.xml (or CustomToolchain.xml) files that specify the toolchain type, ID, version, and other parameters. You can read more about it here.
On top of that, VisualGDB can automatically detect known toolchains from registry via the %VISUALGDB_DIR%\Rules\KnownToolchains.xml file. Specifically, VisualGDB will iterate over each ToolchainLoader element in KnownToolchains.xml, check if the registry value specified there exists and points to a valid directory, and will treat it the same way as if that directory contained a Toolchain.xml file with the contents equivalent to the ToolchainLoader instance. This mechanism is very fast, but cannot detect the exact compiler version in most cases, so it uses the hardcoded value from the ToolchainLoader element (e.g. 5.x).
The new versions of VisualGDB try to detect the version for GCC-based toolchains located via registry by looking at executable names, but it doesn’t work for Keil.
If you manually import the toolchain via the toolchain selector combo box, VisualGDB will get a chance to run the executable to query the exact version from it, and will save it to a separate Toolchain.xml file.
Hence, if you would like each machine to use the same compiler version, you can either remove the manually imported toolchain entry via VisualGDB Package Manager (so that it reverts to the generic registry-based detection), or manually point VisualGDB to the compiler executable, so that it gets a chance to query and record the exact version in a separate file.
Hi,
Your indexing setup appears correct. If you are getting confusing output from gdb, you can try asking at the gdb mailing lists, or checking the gdb source code to understand why the cache doesn’t report any hits.
Another option would be to run the “set debug remote 1” command in gdb. It will force gdb to output all packets it sends to the gdb stub, so you can see if the delay involves any requests to the target.
That said, if you are getting the “virtual memory exhausted” error, it’s likely a gdb bug triggered by something specific about the iMXRT symbols. You can try to narrow it down by stripping the debug information from some object files before the linking, or by building your own gdb executable and stepping through it.
Hi,
Based on the timing view, the delay is coming from the Segger GDB stub and not from VisualGDB. Please consider forwarding this information to Segger support for further help.
Hi,
Indeed, both Visual Studio and VisualGDB can use clang-format. See the following page for more details: https://visualgdb.com/documentation/intellisense/#formatting
Hi,
The assignments for the CC, CXX, etc in stm32.mak are generated based on the toolchain.xml file when you either create the project, or click the “regenerate the MCU-specific files” button on the first page of VisualGDB Project Properties. You can edit the toolchain.xml file in the toolchain directory if you wish to change the values written to stm32.mak.
Hi,
This looks like an issue between J-Link and the Raspberry Pi, rather than something specific to VisualGDB. Please consider contacting Segger support or Raspberry Pi community for further help with this.
Please note that VisualGDB is a productivity tool for software developers. It can make developers more productive by providing convenient GUI for common time-consuming tasks, and integrating various external tools into Visual Studio, so that they are always a few mouse clicks away.
We are able to offer VisualGDB at affordable price, because we focus on developing and supporting functionality that works the same way for multiple users, hence the development and testing effort is reused between multiple license holders.
We also receive a huge amount of inquiries asking to fix a specific broken project, help make the correct design choice, explain how a specific C++ feature works, or assist porting a library to a different platform. These inquiries require considerable effort to research and communicate the best solution. They do not scale between multiple users. I.e. helping one user solve this type of problem will not automatically help other users. It also does not help the same user avoid the same type of problem in the future. Hence, we are not able to address them within our regular support. If we included this type of help in our support, we would simply not have sufficient resources to provide it at the current license prices, or to allocate any resources to VisualGDB development.
We are happy to offer project-specific help via our consulting service per Zoom, TeamViewer or any other screen sharing service of your choice. We charge a fixed hourly rate for these sessions (billed in 1/2-hour increments), and are happy to solve any problems our users encounter. The rate includes a detailed follow-up email at the end of the session, that includes an overview of the used techniques and a summary of solved problems and future recommendations. Please contact our sales if you need more information about it.
Alternatively, please consider browsing our documentation and tutorials. Our documentation lists most VisualGDB settings, and the tutorials show how to use VisualGDB for in many real-world scenarios. Our technical support is limited to issues in VisualGDB itself, that can be reproduced from scratch per our problem reporting guidelines (i.e. do not depend on external projects that can potentially contain errors).
Thanks for the update. If the J-Link gdb stub doesn’t support SMP debugging, there is no easy way to make VisualGDB show both cores in the same session when debugging with it. That said, the gdb stub might open a separate GDB port for the second core, so you can use a second Visual Studio instance to debug it in parallel with the first one. If this works for you (and the Segger can confirm that the stub opens a second port, we can help you configure VisualGDB accordingly).
OpenOCD, indeed, would be another option. You would need to follow the steps below:
- Replace the regular J-Link USB driver with the WinUSB one (VisualGDB can do it for you if you use the USB Devices view).
- Create an OpenOCD script file that would define both cores and enable the hwthread RTOS on them (hwthread is a dummy RTOS that shows each core as a separate thread). You can also specify ThreadX instead of hwthread to have OpenOCD parse the thread state.
- Run OpenOCD with interface/jlink.cfg and your target script. OpenOCD will connect to J-Link and will allow debugging your target as usual.
If your device contains a FLASH memory, OpenOCD may not have a driver for it. However, if you are using our OpenOCD fork (installed by VisualGDB by default), you can make use of the FLASH plugin interface to easily create a FLASH programming driver.
Last time we checked, IAR ijet relied on a proprietary undocumented protocol, and hence was not supported by OpenOCD. That said, IAR might provide their own gdb server executable, that would take the place of OpenOCD, or the J-Link gdb server. If this is the case, we can gladly help you configure VisualGDB to work with it.
