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.

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, 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,

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)?

• This reply was modified 1 year, 6 months ago by support.