Forum Replies Created
-
Posts
-
Hi,
You can use the dump command via the GDB Session window to dump arbitrary memory regions to disk.
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.
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.
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.
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?
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.
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.
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).
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?
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.
Hi,
Thanks, we can address it in v5.3. Can you confirm that the “bt” command issued manually displays the correct (new) stack?
Hi,
Looks like you are trying to debug the .hex file instead of the ELF file (has no extension by default). Please double-check your debug settings; the ELF file contains the necessary symbol information and is vital for debugging.
Hi,
Please use the VisualGDB Project Properties window to create new configurations. It will ensure that all the settings get copied properly.
The Win32/VisualGDB platforms is a side effect of the way Visual Studio manages configurations/platforms. The MSBuild-based projects use the “VisualGDB” platform name, while the rest (e.g. Make-based) use Win32. If you are only using MSBuild, you don’t need the Win32 platform and can normally delete it. If your project uses both MSBuild and non-MSBuild build systems in different configurations, you will have 2 separate copies of each configuration (one for Win32 and one for MSBuild) due to VS limitations.
Hi,
WinGDB is a product that comes from a different vendor, so please contact them for support. If you mean VisualGDB instead, please try enabling the verbose mode via Tools->Options->VisualGDB and check your build output for messages explaining why the files are retransferred.
Hi,
It could be the extern “C” issue. Please try following this tutorial for instructions on fixing it: https://visualgdb.com/tutorials/tips/externc/
