[support]

Hi,

Sorry for the glitch with the forum. We have recently updated the WordPress/bbPress used for the forum, and it turns out that it silently flags posts with more than 1 hyperlink as “pending review”, but doesn’t actually show them anywhere unless you use a special viewing mode.

We have fixed the issue now, pending posts are now properly wired into our internal ticket system.

Regarding the problems with the toolchain, the toolchain testing logic is designed to catch common errors with regular toolchains (e.g. trying the x64 toolchain with an ARM target) and will produce false positives with less commonly used setups. You can simply ignore the errors and should still be able to setup a project. Also, simply ignore the gdbserver configuration as well.

The last error looks like the recently added support for the CXSTM8 toolchain broke MSBuild profile generation for LLVM. We have fixed it in this build: VisualGDB-6.0.101.5158.msi​. If it still doesn’t work, you can try creating a project with CMake instead of MSBuild. It relies on CMake to handle the low-level configuration instead of trying to handle everything on VisualGDB side (it can still trigger issues within CMake itself though).

With LLDB, VisualGDB relies on the lldb-mi tool that allows running lldb with the gdb-mi interface. As of 2024, the tool is unmaintained and not included in the normal llvm repository. VisualGDB includes an older version of lldb-mi based on lldb 6.0, however if it doesn’t work with the FreeBSD lldb server, you would need to either build a newer version yourself from sources, or simply use the gdb/gdbserver setup similar to Linux.

 

 

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

Looks like your browser automatically unzips the package when downloading (it’s a .tar.gz file). The correct (gzipped) MD5 should be ff56c76650114839e718ce8e4265ffac.

You can try downloading it with wget, re-gzipping the unzipped file, or just manually renaming it to .tar and extracting to the destination directory.

[support]

The toolchain.cmake file generated by VisualGDB normally just points CMake to the toolchain executables. Unless you manually edit toolchain definition files, it would not inject any implicit flags there.

You can try completely deleting and reinstalling both VisualGDB and the toolchain and creating a new project from scratch. If the toolchain.cmake file generated by VisualGDB still contains optimization flags after it, feel free to attach it here and we will investigate.

[support]

If you already have an existing toolchain.cmake file, we would advise simply pointing VisualGDB to it instead of creating a new empty one.

Edit: you can also try manually setting DisableToolchainFile in the .vgdbcmake file to false to completely disable the VisualGDB-level handling of toolchain files.

• This reply was modified 7 months, 2 weeks ago by support. Reason: Mentioned DisableToolchainFile

[support]

Hi,

Thanks for the repro steps. If you do not want VisualGDB to generate a toolchain.cmake file, please try using the “Use existing CMAKE_TOOLCHAIN_FILE” option on the import page of the wizard (step 5 in the PDF). You can also change it via VisualGDB Project Properties (Step 6, second setting from the bottom in the first group).

[support]

Hi,

It really depends on how you imported the project and toolchain.

If you need help locating the relevant setting, please make sure you can reproduce the issue on a new project created from scratch. Then, please share the exact steps needed to reproduce it, along with the relevant screenshots, and we will try to point out the setting that is causing this.

[support]

Hi,

Then VisualGDB should not change any flags unless you have overridden it somewhere.

You can export the exact build/configuration commands used by VisualGDB as described here and compare them against the manual build commands.

[support]

Hi,

If this is an nRFConnect project, you can reset optimization options via the first page of VisualGDB Project Properties.

[support]

Hi,

Sorry, these are legacy devices with not that many active users, so we do not support them.

You can probably get it working by figuring out the correct parameters for the underlying command-line tools and manually configuring VisualGDB to use them, but it would be something for you to figure out.

[support]

Hi,

The easiest way to get it working would be to download our Raspberry Pi toolchain and use its toolchain.xml file as a template. The format is pretty self-descriptive: you specify a unique ID, name, paths to various tools, and VisualGDB will run them when building the projects. Fields like tool versions are optional and are used to show meaningful summary in the toolchain selector. Fields related to SD card and target version checks can be removed.

Once you have edited toolchain.xml, you can place it into the FreeBSD toolchain directory, click “locate a new toolchain” in the VisualGDB’s toolchain selector, and point it to the new toolchain.xml file. If you edit the file VisualGDB imported the toolchain, you can open and immediately close Tools->VisualGDB->Manage VisualGDB Packages to reload all changes.

As for LLDB, VisualGDB can automatically detect gdb/lldb based on its reply to “info version”, so you can simply put your lldb executable in the toolchain’s bin folder and add the following line to toolchain.xml:

<GDB>lldb.exe</GDB>

This will override the default name of gdb derived from the <Prefix> field.

If the new lldb binary still doesn’t work, you can try checking the Debug->Windows->GDB Session window in the Raw GDB Output mode. It shows all commands executed by VisualGDB, and their replies. If you can point out specific commands that are not being issued as expected (e.g. require some special flags), we should be able to adjust VisualGDB to accordingly as long as you can confirm that running the updated command manually works as expected.

[support]

Hi,

We merely repackage the toolchain that comes from ARM. If you would like us to do a custom build for you, feel free to contact our sales for a quote.

[support]

Hi,

The linker itself is a 32-bit executable, so it has a 2GB memory limit rather than 64GB.

VisualGDB itself does not do anything special that would affect the memory usage by the linker. It merely launches Ninja, that in turn launches GCC/ld. If it works from developer power shell and doesn’t work with VisualGDB, you can troubleshoot it as follows:

1. Run both builds in verbose mode to obtain the exact linker command lines.
2. Try manually running both command lines from a separate command prompt.
3. If you can reproduce the behavior (one command line triggers the problem, while the other one doesn’t), try comparing the command lines and editing them to gradually remove the differences, until you narrow down a specific option that triggers the problem.

 

[support]

Hi,

It looks like your antivirus hooks the Visual Studio process (possibly, to scan the downloaded file), and than encounters some kind of a internal error. The easiest way around it would be to add Visual Studio to the exception list.

The manual installation should normally work. If it doesn’t, please share the exact URL of the file you are trying to install, and we will recheck it.

[support]

Hi,

Thanks for reporting this. VisualGDB was indeed using a fixed “,” separator when generating CSV files.

We have updated it to use the same system-level setting that Excel does, and also added a manual override option (Tools->Options->VisualGDB->General->Files->CSV file separator).

Feel free to try this build: VisualGDB-6.0.101.5155.msi​

 

[Author]

Posts