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

[support]

Hi,

The log actually shows that VisualGDB rebuilds the entire file instead of reusing the precompiled part. Can you confirm that you see the “PSF 0 (normal preamble) does not match main file.” message even after small localized changes?

Another clue here is that your source code is located on a remote system. Network can introduce significant delays when reading many small files (due to latencies) and that can significantly impact the parse time. Could you try moving the sources on the Windows side and checking if it makes things faster?

[support]

Hi,

You can convert non-MSbuild projects to MSBuild via right-clicking in Solution Explorer, but not back.

BTW, is there any reason why you don’t want to use MSBuild for remote projects? We have thoroughly optimized it to be fast and efficient in both modes (for remote builds it actually generates a temporary Makefile and runs Make on the Linux side), so we recommend it for all new projects.

[support]

Hi,

Thanks, we can address it in v5.3. Can you confirm that the “bt” command issued manually displays the correct (new) stack?

[Author]

Posts