[support]

Hi,

If the public key authentication is not working with a specific machine, it is likely disabled on the SSH server side. You can troublehsoot it by verifying your SSH server configuration/logs.

Indeed, the “Custom GDB Stub” mode does not strip the port from the host name. As a workaround, please try using the “Full-custom mode”. It allows defining the target selection command explicitly.

The “working directory” setting refers to the directory where the custom command is started and does not affect anything else. If you would like to automatically copy any files before debugging, you can explicitly add a custom pre-debug action via VisualGDB Project Properties -> Custom Debug Steps.

[support]

Hi,

No problem, we can clarify what is going on. Your project structure defines the libraries as shown below (the levels correspond to the CMake call stack):

1. register_static_library(StaticLibrary1)
   1. add_bsp_based_library(StaticLibrary1)
   2. register_static_test(StaticLibrary1)
      1. add_bsp_based_executable(StaticLibrary1Test)
2. register_static_library(StaticLibrary2)
   1. add_bsp_based_library(StaticLibrary2)
   2. register_static_test(StaticLibrary2)
      1. add_bsp_based_executable(StaticLibrary2Test)

You have manually defined that register_static_library is the primary statement for the library and register_static_test is the primary statement for the test.

When you try to add sources to StaticLibrary1, VisualGDB walks the definition stack until it finds the register_static_library  statement (1.a => 1) and edits it as expected. This works because StaticLibrary1  (1) and StaticLibrary2 (2) have two physically different register_static_library() statements.

When you try doing the same with StaticLibrary1Test, VisualGDB walks the call stack until register_static_test (1.b.i => 1.b). However both StaticLibrary1Test and StaticLibrary2Test call register_static_test (1.b and 2.b) from the same source location within register_static_library (in functions.cmake).

You can try commenting out the second library definition (register_static_library(Library2 SOURCES Library2.c)) and adding the sources via Solution Explorer. They will be added to the call of register_static_test() exactly as you defined in the test.prop file. However when having 2 libraries, this edit would simultaneously affect both of them, so VisualGDB refuses to do so.

In order for Solution Explorer functionality to work, each target needs to have one unique statement that defines this target and only this target (anywhere on the call stack). E.g. you can refactor your CMake functions so that the call stacks will look like this:

1. register_static_library(StaticLibrary1)
   1. add_bsp_based_library(StaticLibrary1)
2. register_static_test(StaticLibrary1)
   1. add_bsp_based_executable(StaticLibrary1Test)
3. register_static_library(StaticLibrary2)
   1. add_bsp_based_library(StaticLibrary2)
4. register_static_test(StaticLibrary2)
   1. add_bsp_based_executable(StaticLibrary2Test)

You would need 2x the statements in the main CMakeLists.txt file, however as each statement is now uniquely associated with a target, solution explorer logic will work just fine. If you would like to minimize redundancy, the register_static_library() function can set some custom properties on the created target, and register_static_test() can query them so you wouldn’t need to specify them twice. You can search the VisualGDB CMake files for get_target_property() to get the basic idea.

You can also keep the current layout and export the TESTSOURCES parameter of register_static_library() as a custom property (e.g. see bsp.hwregister_list_file in bsp.prop). It will be editable via the VS properties window, but not via the add/remove files commands.

[support]

Hi,

This looks like something between OpenOCD and your chip and not specific to VisualGDB. If using STM32CubeIDE works, please try extracting an OpenOCD configuration script from it and manually specifying it in VisualGDB settings. You can also try selecting the ST fork of OpenOCD instead of the default fork to minimize the differences between them.

[support]

Hi,

Our Clang IntelliSense uses Clang 6.0 that supports many of the C++20 features. That said, since it uses the headers directly from your toolchain, the toolchain must support C++20 as well and it should be selected via the “language standard” setting in project properties, as many toolchains default to a lower C++ language standard version.

[support]

Hi,

Please try creating a new MSBuild-based project using the VisualGDB project wizard corresponding to your project type. If the newly created project works, please try comparing the .vcxproj files of the old vs. new project.

If you find multiple differences, you can try eliminating them one-by-one by manually editing the files. Once you find a difference that is causing the issues, you can manually apply it to the old files.

[support]

No problem. Feel free to bump this thread once ESP-IDF v5 is officially released (not beta) and we will provide a timeline on fully integrating it.

[support]

Indeed, since Visual Assist relies on the regular VC++ IntelliSense engine, it won’t work with the projects using Clang IntelliSense. And disabling Clang IntelliSense naturally disables all features provided by it, such as Code Explorer.

That said, if you miss specific functionality from VisualAssist that is not provided by the Clang IntelliSense, feel free to use let us know. We might be able to add it to one of the future versions of VisualGDB.

[support]

Thanks, we have confirmed the issue and found the root cause. The latest nRF52 Arduino package changed the OpenOCD command template to a format that was not supported by VisualGDB:

tools.openocd.upload.pattern="{path}/{cmd}" -s "{path}/share/openocd/scripts/" -f "{runtime.platform.path}/variants/{build.variant}/{build.openocdscript}" -c "program {{{build.path}/{build.project_name}-merged.hex}} verify reset exit"

The extra {{}} after the ‘program’ argument intended to pass the literal ‘{‘ and ‘}’ to OpenOCD was not properly translated.

We have updated VisualGDB to handle this correctly. Please try this build: VisualGDB-5.6.108.4712.msi

[support]

Hi,

Please refer to the following page for more details and troubleshooting instructions: https://visualgdb.com/documentation/colors/

[support]

Hi,

This looks like some part of the project settings got corrupt, although it’s hard to tell anything specific without knowing more context of the issue.

Please try reverting the project to the last version that worked. If you can then point out a specific setting that triggers the issue, we can gladly release a hotfix for it, or suggest a workaround.

[support]

Hi,

The steps you provided involve importing a 3rd-party project. If you would like to get it working with VisualGDB, please make sure you can build it by running CMake/Ninja manually on the same machine using the same toolchain. If the project doesn’t build/work on your platform, it may need to be ported to it and VisualGDB cannot do it automatically.

Once you get the manual build to work, please share:

1. The manual CMake command line that produces a successful build
2. CMake command line from the VisualGDB build log

We can then help you adjust the VisualGDB settings to match the manual build command line that works.

• This reply was modified 2 years, 10 months ago by support.

[support]

Hi,

The KGDBoE module relies on several APIs that slightly vary between different kernel versions (distro-specific patches make this even harder). You can try using the latest KGDBoE version from our repository – it works out-of-the-box with Ubuntu 22.04.

That said, if you are new to Linux kernel development and do not wish to troubleshoot KGDBoE compatibility issues, we would advise using one of the supported virtual machine types with the VM-specific debugging interface. As the VM-based debugger runs outside of the kernel, it doesn’t need any special adjustment and usually just works out-of-the-box.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

We will monitor replies on this thread. If sufficient users with active licenses post that they are interested in GD32 devices, we will consider supporting them directly. If anyone agrees to cover the research and testing costs directly, we will also be happy to do it.

If your project depends on the GD32 devices, yet ordering a custom BSP from us does not make economic sense, you are welcome to do the research on your side and setup a project manually. The rest of the VisualGDB functionality will work just fine.

[support]

Hi,

This looks like more of a generic CMake question than something specific to VisualGDB. Feel free to post it on CMake forums, if you get a CMake-specific advice, we can help you map it to particular VisualGDB settings. You can also dump the CMake command line used by VisualGDB to a batch file as shown here, and experiment by modifying the CMake command line directly instead of going through various VisualGDB settings. If you find a command line that works better, we can help you find VisualGDB settings that will replicate it.

The CMake files shown in Solution Explorer (including multiple instances of toolchain.cmake) are reported by CMake via the cmakeFiles-v1-<ID>.json files. The one used by VisualGDB should have the path of C:\Users\ XXX \libjpeg-turbo-2.1.4\./build/VisualGDB/Debug/toolchain.cmake. You can try using our CMake debugger to find out which file references the second one.

[Author]

Posts