Forum Replies Created
-
Posts
-
Hi,
Please make sure you use an unmodified installer of VisualKernel downloaded from our website.
If it still doesn’t work, please let us know the email address associated with your license key so that we could check your support status.
Hi,
No problem, we can help you. The build errors happen because the LiveMemoryEngine.c file (responsible for the new Live Watch feature) cannot find the definitions of kthread_should_stop(), kthread_run() and kthread_stop() functions. The functions are defined in the kthread.h file that should normally be included from one of the headers already referenced from Live MemoryEngine.c, however it may be different in the kernel version you are using.
Do you mind adding #include <linux/kthread.h> to LiveMemoryEngine.c manually and trying to debug again? If this solves the problem, we will update it on our side.
Regarding the .ko file issue, could you please clarify how is the file referenced? Is it one of the modules indexed together with the kernel release, or are you building it manually? Also if you could attach the relevant .vkrnlproj/KernelRelease.xml files, we should be able to pinpoint the issue faster.
You can if you follow the steps outlined in the documentation and tutorials. If you are doing something different from the steps suggested in the documentation, you will inevitably get different results.
We have asked you to provide the steps to reproduce the issue beginning from VS launch, accompanied by the uncropped screenshots, so that we could point out what you are doing incorrectly. Instead, you have provided ambiguous steps and attached 3 instances of the same cropped screenshot that does not show sufficient context.
We will not be able to help you based on the information you provided and have to close the issue. If you require further help, please do read and follow our problem reporting guidelines. We will not be able to provide any further replies unless you provide the information we requested.
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:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- 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.
- 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.
Hi,
If the compilation is working, most likely some parts of the platform headers use C++20 features that are not yet supported by our Clang IntelliSense engine. We are planning to release a major update to the engine in the next few months, so it should take care of it.
Until then, the only way to troubleshoot such issues would be to narrow them down to a specific broken identifier, checking where it is actually defined, and trying to move the definition around to see what triggers the issue. Most likely, IntelliSense stops parsing when it encounters a very specific language construct that it cannot work around, so the entities declared after it are not recognized. If you can locate a specific construct causing it, you can try wrapping it with #ifndef __SYSPROGS_CODESENSE__ so that the IntelliSense engine will ignore it.
It is hard to say why it wouldn’t work without the full context, as VisualGDB should normally automatically strip the custom port from the host name. If setting the SSH port to 22 works, it should be a reasonable workaround.
If not (or if anyone else encounters a similar issue), please feel free to share the repro steps per our problem reporting guidelines and we will investigate this further.
It is hard to say why it would not be working. Please try opening the CustomCMakeTargetDemo.sln solution from the tutorial directly. If it doesn’t work, please let us know and we will recheck. If it works, please try comparing your .vgdbcmake file against the one that works. If you find multiple different settings, you can try copying half of them at a time into the broken project and reloading it to see if it fixes the issue.
If you can pinpoint a specific setting that is breaking the template functionality, feel free to let us know and we will help you get it working.
According to our records, your support is still not active. If you believe this is a mistake, please contact our technical support with your license details.
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:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- 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.
- 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.
The target is the machine where you would like to physically run gdb and is usually to the build machine to avoid confusion (there is a checkbox on the Project Settings page to override it). In this case, it should be the local machine. In order to manually connect to QEMU, please try entering “target remote <host>:<port>” into the target selection command field.
Hi,
According to our records, you do not have an active support period, hence we will not be able to help you. If anyone else wishes to help, they are welcome to post in this thread.
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.
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):
- register_static_library(StaticLibrary1)
- add_bsp_based_library(StaticLibrary1)
- register_static_test(StaticLibrary1)
- add_bsp_based_executable(StaticLibrary1Test)
- register_static_library(StaticLibrary2)
- add_bsp_based_library(StaticLibrary2)
- register_static_test(StaticLibrary2)
- 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:
- register_static_library(StaticLibrary1)
- add_bsp_based_library(StaticLibrary1)
- register_static_test(StaticLibrary1)
- add_bsp_based_executable(StaticLibrary1Test)
- register_static_library(StaticLibrary2)
- add_bsp_based_library(StaticLibrary2)
- register_static_test(StaticLibrary2)
- 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.
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.
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.
