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

[support]

Hi,

If VisualGDB adds the “-select IP=127.0.0.1:2331” argument, it means that you have changed the connection mode from “USB” to “TCP/IP”, that doesn’t match the screenshot you provided. If you manually change the “-port” argument to 2331, it will not work because JLinkGDBServer will try to use the same port to connect to GDB and J-Link hardware (that should be using USB instead).

Please do not do this. Changing random settings without understanding them, and mixing screenshots and logs from different setups never works and makes it completely impossible to troubleshoot anything.

If you still cannot get it working, please try creating a new project from scratch, selecting J-Link via debug settings and then:

1. Using the “test” button to verify the connection without changing any other settings.
2. Running the exact command line from the “test” window without changing anything else.
3. Running GDB manually, and connecting to the port specified by “-port“.

If it doesn’t work, please attach:

1. The screenshot of the debug settings
2. The entire log (including command line) from the test window
3. The entire output (including command line) when running JLinkGDBServerCL manually
4. The entire output (including command line and all commands) from gdb

If you change anything else, please do explicitly mention it and make sure your screenshots reflect it. Otherwise, it will not work.

[support]

Hi,

There are 2 different ports involved in it. The one passed via -select refers to connecting JLinkGDBServer to J-Link hardware via TCP/IP (as opposed to USB). The one passed via -port refers to the port used by gdb to connect to JLinkGDBServer.

You can try clicking the “test” button on the Debug Settings page of VisualGDB Project Properties. It will launch the J-Link GDB server and will show the used command line. You can then try closing it, running it manually, and then starting GDB (pointing it to the correct ELF file) and running the following commands:

target remote :<GDB port specified via -port>
load
b main
continue

If this works (i.e. breakpoint in main() triggers), but debugging with VisualGDB still doesn’t work, please attach the gdb log from VisualGDB along with the output from running the gdb commands manually, and we will help you find the difference.

 

[support]

Please make sure you can run the J-Link gdb server manually, connect gdb to it and debug the ELF file produced by the Arduino project.

Once this works, feel free to share the details (e.g. exact J-Link gdb server command line that worked), and we can help you configure VisualGDB to replicate that setup.

[support]

Hi,

Sorry, we haven’t specifically tested VisualGDB with gRPC and do not have any instructions for it. Our best advice would be to first get it working outside VisualGDB using the same target/toolchain, and then modify your VisualGDB project accordingly.

[support]

Hi,

The “must specify support pico_cyw43_arch architecture” error could be triggered when trying to build Pico W samples for the regular Pico board or vice versa. Please make sure you select the PICO_W target in the wizard if you are using Pico W samples.

The other message looks like something in the SDK is broken. You can try resetting the SDK installation as follows:

1. Completely delete the toolchain directory.
2. Completely delete all PicoSDK checkouts from %LOCALAPPDATA%\VisualGDB\PicoSDK.
3. Completely delete CMake from %LOCALAPPDATA%\VisualGDB\CMake
4. Restart Visual Studio.
5. Create a new Pico SDK project completely from scratch, letting VisualGDB download all necessary tools.

 

[support]

Hi,

The “Easy GUI for managing additional memories” in the Custom edition refers to this feature. It provides a GUI for adding memories and associated sections to linker scripts instead of editing them manually. It only works for classic embedded projects (not Arduino/Mbed/ESP-IDF). If you do not need this feature, or any other Custom/Ultimate features, you can contact our support, and we will revert the upgrade.

If you would like to get debugging working on WLR089, please make sure Segger J-Link actually supports it and can work with it via command line (by launching their gdbserver manually). If J-Link cannot communicate to the chip, using VisualGDB on top of it won’t automatically fix it.

[support]

Hi,

This is by design. You can try using the “Run All Tests” or “Run Selected Tests” commands to run multiple tests. VisualGDB will record the call stacks for the failing ones, and automatically continue running the remaining tests. Then, once you narrowed down a specific failing test, you can run just that test in debugger, and VisualGDB will automatically stop the debug session when the test failure occurs. You can still press F5 to continue to the next test though.

If this doesn’t work, feel free to describe what you are trying to achieve, and we will try to suggest a better way to do it.

[Author]

Posts