Forum Replies Created
-
Posts
-
Hi,
CMake-based tests should work just fine. Most likely, some of the settings you specified are preventing them from working.
We can help you get it working if you could share the steps to reproduce the problem from scratch:
- 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. See this page for more information and detailed examples.
- 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.
Hi,
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. See this page for more information and detailed examples.
- 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.
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,
Most likely, you have enabled the Tools->Options->VisualGDB->General->Debug->Remember Quick Debug Sources setting, so VisualGDB keeps reopening the previously open files.
If this is not intended, please consider disabling the setting.
Hi,
You can try running the strip tool from the ARM toolchain:
arm-none-eabi-strip.exe <Library file>
If you would like to do it automatically, you can add it to VisualGDB Project Properties -> Custom Build Steps -> Post-Build Steps.
Hi,
Indeed, this should work. You can edit this setting via GUI by selecting the BSP in Solution Explorer and opening its properties. See this page for a detailed overview of the embedded CMake projects and various options that can be edited.
Hi,
The project importing logic can automatically handle the most common settings (device type, list of sources/headers, include directories, preprocessor macros, libraries, scatter file). If your project is considerably more complex, it may indeed require manual adjustment after importing.
There are 2 ways to address it:
- You can try creating a new project from scratch as shown in this tutorial, and compare it against the broken one.
- You can try following this tutorial to compare the build command lines between the original Keil project and the imported project.
If you prefer, we can compare the projects for you over a screen sharing session, and fix all the issues, however we would have to charge our consulting rate for it, since it is not something that can be done fully automatically.
Hi,
Sorry about that. The ftrace_ops error looks like our previous fix was incomplete. It’s not about the kernel version, but rather about the kernel being built without ftrace. We have fixed it in this build: VisualKernel-4.0.101.2367.msi
The issue with the list of functions is different – most likely your custom kernel uses some parameters that confuse some of the VisualKernel’s parsing logic. We have tested it against several different platforms and kernel versions, but never encountered this error. Would you be able to share your vmlinux file with us so that we could retest it on our side? If not we can add some extra logging to pinpoint the root cause, but it would take longer. For what it’s worth, you can also try hitting “cancel” after most modules within the kernel have been indexed – VisualKernel with proceed with what it indexed so far, allowing you to set tracepoints there.
Also with performance, the initial indexing could indeed take long (takes about a minute on i9-12900KS), however once it is done, VisualKernel saves the indexed symbols in its own optimized format, and loads them next time almost instantaneously.
With KDB, VisualKernel just runs this command line as root:
sh -c -"echo g > /proc/sysrq-trigger"
If you are triggering sysrq differently, please let us know. You can also try checking VisualKernel Diagnostics Console (you may need to grep the log for SSH). It shows all SSH commands issued by VisualKernel, so you can always compare them against the manual list. But if the version without KDB works, it could be indeed an easier solution.
Edit: the traceable symbol indexing should not normally show the number of processed files unless you are looking into the debug view. Are you sure you did not accidentally start IntelliSense indexing instead (e.g. via CodeJumps)?
No problem, please try this build: VisualKernel-4.0.101.2366.msi
In order to experiment with KDB->KGDB switching, please try disabling the explicit KDB->KGDB switch via settings, then open the .vkrnlproj file manually, and set the following elements:
- ExplicitSwitchFromKDB to false
- ManualSwitchFromKDB to true
VisualKernel will then display a message box asking you to do the switch manually after issuing a sysrq, but before connecting to the COM port. If this works, we can add a proper setting to run an arbitrary command line.
The new build also supports tracing without debugging. You can enable it as shown below or via Debug->Start VisualKernel Tracing Session. Tracing sessions run directly over UDP, do not require any other connection, however they do not stop the target, and instead record the selected variables in the background. You can use the techniques shown in our tracing tutorial to see what is going on at the target.
P.S. The tracing engine is a brand new feature, we are open to feedback on it and should be able to iterate on it very fast.
Hi,
Based on a quick search, the error code looks like some Windows files got corrupt (see this thread), so it’s hard to suggest a workaround that would definitely work.
You can try using Zadig – it uses a slightly different API for generating the drivers; another option would be to import the installed driver from another machine where it got installed (locate/copy the oemXXX.inf/.pnf/.cat files and point the Device Manager to the copied version), although it again may not work if some driver-related functionality is broken on your machine.
No problem, we have rechecked the Kernel Release workflow with the 3-machine setups, and indeed it was somewhat confusing. You can still add the .vkrnlrelease files to Solution Explorer by copying the full path to the Open File dialog, but it wasn’t suggesting the .vkrnlrelease extension automatically.
Please try this build: VisualKernel-4.0.101.2361.msi. It will now show the .vkrnlrelease files in the Add->Existing Project dialog, and will also point to the files inside the kernel release when stopped in a debugger, as long as the kernel release project is added to the solution.
Hi,
These errors come from the recently introduced Live Tracing engine that indeed was not tested with the older kernels (it works just fine with the recent 5.x versions though).
We have updated VisualKernel to automatically detect it and turn off the tracing engine if it detects an incompatible kernel. Please try this build: VisualKernel-4.0.101.2361.msi
If you would like to use Live Tracing on an older kernel, we can gladly backport it for you as long as you purchase a Standard VisualKernel license. If you would like to evaluate Live Tracing before purchasing, you can try it out on a more recent 5.x kernel (stock kernels coming with most Linux distros will work just fine).
Hi,
Sorry about the forum glitch. It appears to happen very rarely due to some cookie issues, however we were never able to reproduce it reliably.
Please try this build: VisualKernel-4.0.101.2360.msi. We have updated VisualKernel to automatically detect #include <stdarg.h> vs #include <linux/stdarg.h>. The error with ftrace_ops looks like your could you place check whether your ftrace.h file defines ftrace_ops? You can include it from any kernel module (or by temporarily editing any of the kernel sources) and IntelliSense will conveniently highlight the parts that are being parsed.
We have also updated VisualKernel to explicitly log where it issues the KDB->KGDB command. You can try enabling View->Other Windows->VisualKernel Diagnostic Console, start a debug session and double-check that it contains the “Sending ‘kgdb’ to COMx @<baud>” line. If if helps, we can also add a setting to display a message box after doing a sysrq trigger, so that you could try sending it manually in a terminal program and see if it works.
Regarding the frozen mode, enabling this mode updates the project file, so Visual Studio considers it outdated and tries rebuilding it, triggering a connection error. It should normally fail to connect, then ask you whether you want to try debugging the previous build result, and then it should work just fine. You can also try setting Tools->Options->Projects and Solutions->Build and Run->On Run -> Prompt to Build. This way Visual Studio won’t try to automatically build the outdated projects and you can choose to run it without having to wait for a connection timeout.
P.S. We have recently added a new feature that allows tracing arbitrary kernel functions and source lines (i.e. instead of stopping in a debugger, it just records the variables you selected and lets you review them later). It currently requires a regular debugging connection, however we are working on an update that will allow doing it without just a network connection (no KGDBoC/KGDBoE/JTAG required). Because of the delayed nature of tracing (the actual data transfer happens after everything has been recorded), it doesn’t cause any instability and works much faster than most debug methods. Let us know if you would like to try it out.
No problem. We did recheck it with shared projects, so the issue could be caused by something else (e.g. symlinks in the target paths or some particular path syntax).
It could have the same underlying cause as the synchronization problems, but it’s hard to pinpoint anything specific from the observations you are describing.
That said, you can track down the second problem fairly fast as shown below:
- Isolate a specific file that is not being re-uploaded. Confirm that just changing that one and building file doesn’t get it uploaded.
- Create a new project with just one file from scratch. Confirm that re-uploading works with the brand new project.
- Try gradually changing both new and old projects until they are equivalent (e.g. remove some files from the old one, add some files to the new one), rechecking the behavior after each step.
It typically takes less than 10 steps and almost always boils down to a 2-3 settings that were changed together in an unexpected way, and had an unintended side effect. You can also use diffing tools (e.g. KDiff3) to speed up the comparison.
Also, if you wish, we can do it for you via a screen sharing session at our consulting rate. It should take less than an hour to get it all sorted out (you only pay if it worked), however our consulting rate is fairly high and may not pay off depending on your constraints.
Hi,
Sorry about the build error. We have indeed recently replaced #include <stdarg.h> with #include <linux/stdarg.h>, resolving build issues on some kernels, and did not encounter any problems with the new version.
Can you confirm that changing it back to #include <stdarg.h> in the VisualKernel directory solves the issue? If yes, we can easily add an auto-detection logic for this.
Regarding KDB->KGDB, we added this feature while investigating the KGDBoC timeouts, however it turned out that it should not be normally needed – if you connect GDB to KGDBoC that is stuck in KDB mode, it should automatically detect it and switch, as long as the GDB timeouts are sufficient. We kept the new setting in place in case it helps work around other issues, however it currently only works when the COM port is connected to the Windows machine directly. If you are running GDB on Linux and connecting to /dev/pts/3, you can force the KDB->KGDB switch by running the following command line before connecting gdb:
echo kgdb > /dev/pts/3
This needs to be run on the gdb machine, so the target does not need to be accessible via SSH at this point. If this works better, let us know and we will update the switching logic to run this automatically.
