[support]

Hi,

For custom build, VisualGDB would actually expect you to configure IntelliSense manually. Hence manually editing the gcc_Debug.h file would be the recommended option.

If it does not help, please try using the ‘Go to definition’ command to locate the macro definition. Also please double-check that you are using the Clang IntelliSense engine and not the native VS one.

[support]

Hi,

Thanks for reporting this, we have fixed it in this build: VisualGDB-5.2.16.1459.msi

[support]

OK, thanks. We should be able to reproduce and fix it in v5.3. We will post an update here once we have a preview build with this feature.

[support]

Hi,

This could be indeed related.

We are actually planning to improve the large directory downloading in VisualGDB 5.3 and will reinvestigate this when adding the new feature. As a temporary workaround, please either try running VS as administrator, or temporarily remove the symlink during synchronization.

[support]

Hi,

If it only occurs once every few months, it’s probably easier to just ignore it rather than to try locating the cause. If it starts occurring more often after some specific change, let us know and we will try reproducing it on our side.

[support]

Hi,

Yes, you can experiment with the default Windows path for relative paths via VisualGDB Project Properties -> Path Mapping.

[support]

Hi,

The Clang IntelliSense caches the old file paths in the global file table in order to speed up the up-to-date check operations. The message can be safely ignored, but you can also simply remove the CodeDB directory to discard the IntelliSense cache.

[support]

Hi,

You can use the dump command via the GDB Session window to dump arbitrary memory regions to disk.

[support]

Hi,

The user variables are supported starting from the Custom edition. If you are using a lower edition, VisualGDB won’t display the related property pages.

You can always upgrade your edition via http://sysprogs.com/splm/mykey or simply use the Windows environment variables instead if you don’t need the other Custom edition features.

[support]

Hi,

It is defined there because VisualGDB normally defines the DEBUG macro for the debug configurations to distinguish them from release ones.

You can simply remove it from the “preprocessor macros” field via VisualGDB Project Properties and click “Apply” to regenerate the gcc_Debug.h file automatically.

[support]

Hi,

Sorry, we don’t support Zynq directly as it’s not as popular as other platforms and the tools are not very reliable. Feel free to try it and post any errors you encounter. We will try to help you resolve it, but we cannot guarantee that it will work.

[support]

Hi,

Normally VisualGDB should recognize the symlink and convert it to a corresponding directory symlink on the Windows side. If this does not happen, could you share the error message you are getting?

[support]

Hi,

No problem. You can still use the GNU Make for remote builds and MSBuild for local ones, but it will require manually moving the settings around if you want to keep them synchronized. If something does not work with this setup, let us know and we will help you fix it, but it will be somewhat less intuitive and less straight-forward than using the same build system for all configurations, sorry.

Just FYI: for MSBuild projects you can still use VisualGDB Project Properties to edit common settings like Include Directories. We specifically designed a page with the same look&feel as the regular Makefile properties that edits the underlying MSBuild properties to make it easier for users who are got used to the Make-based projects.

[support]

Hi,

Thanks, the +0x10 is indeed a bug on our side. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1458.msi

Regarding the local variables, it could be quite time-consuming to query their ranges from gdb, so we don’t currently do it. We will re-investigate this in v5.3 and will consider adding an option to do that.

[support]

Hi,

Thanks for clarifying this. This is a known issue that was not addressed as it only occurs once after the initial import. It does look like a major disturbance with git, so we will fix this in the early preview builds of VisualGDB 5.3 (available in the next 1-2 months).

[Author]

Posts