[support]

Hi,

Thanks for sharing this. We finally received our RP2350 board, tested it out and released an updated OpenOCD package that supports RP2350 out-of-the-box. Feel free to update via VisualGDB Package Manager.

Due to reasons unknown, the Raspberry Pi developers combined the RP2350 support with an unknown subset of other commits from the OpenOCD repository into a single large commit, so it is not easy to fully port it into the mainstream OpenOCD. So, our package currently includes a separate OpenOCD executable for RP2350 based on the Raspberry Pi fork (openocd-rp2350.exe). VisualGDB will handle it transparently, as long as you select one of the rp2350_xxxx.cfg scripts.

As for VisualGDB 6.0R3, you need to select the Pico 2 device manually (the auto-detection logic cannot distinguish Pico 2 from Pico 1 yet), but an upcoming update to VisualGDB will resolve it.

[support]

Hi,

The HAL configuration file is used by both the application and the HAL itself. Hence, adding the include directory for just the application won’t be sufficient.

Instead, you would need to add it for the entire BSP using the VS properties for the BSP item in Solution Explorer or using the bsp_include_directories statement.

[support]

Hi,

This is somewhat of a known trade-off. Visual Studio requests a lot of background information from VisualGDB quite often, so it somewhat limits how much details about the project it normally collects, and tries to cache as much as possible.

That said, detecting changes to host aliases and using the correct deployment directory for custom shortcuts is doable without too much slowdown. Feel free to try this build: VisualGDB-6.0.103.5211.msi.

[support]

Hi,

Please refer to the ESP-IDF documentation for an explanation of the ESP-IDF project structure.

[support]

Hi,

Please refer to the ESP-IDF documentation for more information about components.

If you are curious about what exact files get edited when you change a particular setting, you can follow the steps below:

1. Make a backup of the project, or commit it to Git.
2. Change the setting and reopen the solution to make sure it is saved.
3. Compare the old and the new version of the project using an external diffing tool.

[support]

Hi,

No problem. First of all, please try this build: VisualGDB-6.0.103.5206.msi. It fixes the BuildHost/DeployHost variable behavior and adds a height limit to the custom action list.

We also added a new command for deploying the output of the startup project (and its dependencies) without debugging (Debug->Deploy Project Output).

If you would like to combine it together with debugging the C# code, you would need to use a 3rd-party macro extension to set the startup project to the VisualGDB one, run the deployment command, set the startup project to the C# one, and finally launch the debug session. The DTE name for the “deploy project output” command is Debug.DeployProjectOutput.

If you would like to deploy the .so files and start debugging the mono process, the easiest way would be to define a dummy executable that is linked against all the .so files (so VisualGDB will treat them as dependencies and will deploy them), and then override the gdb/gdbserver command lines to actually debug mono instead of the dummy executable.

If you would still like to run the VisualGDB custom shortcuts programmatically, we can modify the DTE command handler on our side to accept the shortcut number (or name) as a parameter, if you have a convenient way of running custom DTE commands.

[support]

Hi,

No problem, we have made the $(TargetPath) check optional in this build: VisualGDB-6.0.103.5206.msi. It also fixes the BuildHost/DeployHost variable behavior when using aliases.

That said, using the mono path inside sysroot should be the way to go. If the gdb machine has a different architecture than the target machine, the /usr/bin/mono executable could give GDB all kinds of incorrect hints, resulting in weird glitches across the board.

[support]

Hi,

Thanks, this is very strange, but easy to work around. You can clear the VisualGDB Project Properties -> Debug Settings -> Common Settings -> Debugged Executable field, or outright switch the debug mode to “fully custom” and specify the command line explicitly (the –interpreter mi part should still be present).

[support]

Hi,

Then the sysroot directory should be already present and it should be fairly easy to get it working:

1. Try running the exact gdb command line shown by VisualGDB in the log file.
2. Try manually issuing the gdb commands issued by VisualGDB. You can dump them into a text file and load it via the “source” command. You can filter out “-gdb-show” and other commands that are unlikely to change anything.
3. Confirm that the problem persists and that it works when running gdb without any extra commands.
4. Try removing half of the commands copied from VisualGDB and checking whether the problem persists.

Once you narrow down to a specific command that causes the problem, we can help you find the setting to adjust it.

You can also quickly try checking the values of sysroot and solib-search-path in the working session, and forcing them via VisualGDB Project Properties -> Additional GDB Commands -> after selecting a target. But if it doesn’t help, doing the side-by-side comparison as shown above should work.

[support]

Hi,

This is somewhat of a known issue, however it could be non-trivial to untangle. The most important lines here are these:

[ 5113 ms] ~"Reading /lib64/ld-linux-x86-64.so.2 from remote target...\n"
[ 5114 ms] &"warning: File transfers from remote targets can be slow. Use \"set sysroot\" to access files locally instead.\n"
[ 5114 ms] &"warning: Unable to find dynamic linker breakpoint function.\nGDB will be unable to debug shared library initializers\nand track explicitly loaded dynamic code."

This means that GDB cannot figure out how to detect when shared libraries are loaded (i.e. the .so file you are trying to debug), so it won’t be able to set breakpoints there.

To fix this, you need to find the unstripped file corresponding to /lib64/ld-linux-x86-64.so.2, and make sure gdb can load symbols from it. If you are using yocto, the build process might already produce the symbols and put them into a separate sysroot directory. If this is the case, all you need to do is issue a set sysroot command to gdb, pointing it to the correct sysroot with the symbols. If not, you would need to locate the symbol file manually, and either recreate a sysroot directory on the gdb machine, or just put it to some location and add it to solib-search-path.

As for debugging the managed code, VisualGDB doesn’t have any special support for it, however you can still use the gdb debugging techniques from Mono documentation. We can also give you a quote for properly supporting Mono debugging as a custom feature, however it would be rather non-trivial and may require additional maintenance to support future Mono versions.

[support]

No problem, we will try to clarify. We get a lot of requests to change various things and often discover problems proactively as well. So, we have to prioritize them. E.g., issues that break workflow for multiple users (e.g. recent Qt6 update breaking our Raspberry Pi toolchain) get higher priority than annoying glitches that trigger only under certain rare circumstances.

Adding an extra set of checks to a rather complicated mechanism always has a chance of backfiring and causing unintended behavior someone else with another rare combination of settings, so it requires more testing and hence gets pooled together with other similar minor changes in the same area.

The behavior mentioned by @bflannery was actually a bug introduced by switching to a newer Clang version (entering names for new variables should not trigger the completion at all) and is already fixed in our development branch. As for the setting, we should be able to add it next time we change other logic related to completion, however we cannot promise any deadlines for it now, sorry.

[support]

Hi,

We are not aware of this issue. It could be caused by a bug in a particular toolchain that doesn’t report some of the include directories correctly, or by a bug in VisualGDB that prevents it from interpreting the reported directories.

In order to fix it, we need to be able to reproduce it on our side. Please provide the complete steps showing how to reproduce the problem from scratch, including the screenshot of every wizard page, and every window where you change any setting, so that we could try reproducing it here.

You can also disable the detection of missing include directories using the “X” button on the right side of the popup.

[support]

Hi,

The first error looks like a corrupt package or too old VisualGDB version. Installing the latest VisualGDB 6.0 should solve the problem.

The second one looks like the Python environment is corrupt or incompatible with the ESP-IDF version you are using. Please try completely resetting the toolchain as shown here.

Normally, as long as you clear the Python path, VisualGDB will automatically start using the one from %LOCALAPPDATA%\VisualGDB\Python-<Version>. However, if you had previously installed some extra packages into it, it could break compatibility with ESP-IDF. Please make sure you delete the Python directory when you reset the Python environment, and let VisualGDB re-download a clean one from scratch.

[support]

Hi,

Sorry, we do not have a tutorial on VxWidgets. Our best advice would be to get the project working outside VisualGDB first using the same target and toolchain. Then importing it into VisualGDB should be fairly straight-forward.

[support]

Please follow the troubleshooting instructions from our previous reply. If you cannot get a working GDB+JLinkGDBServer session outside VisualGDB, the problem is not on the VisualGDB side and it will not work with VisualGDB either.

[Author]

Posts