[support]

Hi,

It is hard to say why the specific thread would not be recognized without knowing the exact repro steps. If the problem only happens on a specific project/board combination, please try building our RTX plugin from sources and stepping through ReportThreadList() to see why a particular thread is skipped.

[support]

Thanks for clarifying this. In that case, indeed QEmu could one of the best bets, although configuring it would be non-trivial.

Generally, Qemu supports the gdb stub mode similar to VWMare, so we would advise the following configuration:

• Forward SSH port from the target to 10022 or any other port and specify “localhost:10022”  as the host name in VisualKernel.
• Enable the gdb stub mode in Qemu and use the “custom” mode in VisualKernel, directing it to connect to the specified host/port.

That said, due to low reliability of Qemu, this setup may trigger strange bugs, or not work at all.

[support]

Sorry, we absolutely do not support Qemu. It is extremely unreliable and difficult to configure. Please try using VMWare instead.

[support]

Good to know it works and thanks for the suggestion.

Unfortunately, automatically repairing broken package repositories would not be realistic. File system corruption is very unpredictable, so the exact repair actions would be completely different in each case.

As a workaround, unless you are debugging drivers for hardware that cannot be virtualised, please consider using VM snapshots as a way of recovering from file system corruption.

[support]

Thanks for posting the screenshots. It looks like the in the “correct” step the file is not saved. Could you please check whether the problem gets immediately triggered by saving the file, rather than building the project?

Also please try replacing the entire contents of the main file with this:

enum
{
    MY_TEST_ENUM = 1
};

void test()
{
    int x = MY_TEST_ENUM;
}

Then save the file and try going to definition of MY_TEST_ENUM. Does it work? If yes, try reverting to the old file contents and putting both the definition and the use just after the #include<> block.

If this doesn’t work, try putting it before the #include<> block.

If placing it just after #include<> block works, try keeping the definition on top and moving the use at the end of the file. If this triggers the problem, try locating a specific spot in the source file, after which the go-to-definition stops working. Most likely, it has some special character that confuses Clang. If you could eliminate the references to external code (so that it would load on our side), zip the repro file (to preserve encoding) and send it to us, we should be able to fix this.

 

[support]

Hi,

The AdditionalIncludeDirectories variable exists on the MSBuild level and is not generally passed to the VisualGDB level (to make things more complicated, it is not a global MSBuild variable, but a property of each individual ClCompile item).

To work around it, you would need to create a custom MSBuild target, translate %(ClCompile.AdditionalIncludeDirectories) into a global variable (just placing <PropertyGroup> inside the custom target might work) and then use the <Exec> task to launch the custom tool. The rest of the variables you mentioned are available both on VisualGDB and MSBuild level, so they will work in this scenario as well.

An easier alternative would be to create a basic property sheet defining the include directories (see the stm32.props file created by VisualGDB for embedded STM32 projects), referencing it from your project and parsing its contents from the custom tool. This will avoid complex MSBuild scripting and will still avoid having multiple redundant definitions of the include directories.

[support]

Sorry, we have not explicitly tested VisualGDB with Jenkins yet. Producing the .trx file with the /vsoutput option and then using the regular MSTest plugin should normally work. If not, please share the details and we will try to help you configure it.

[support]

Thanks for reporting this. We have fixed it in our development branch and will include in the next VisualKernel update.

[support]

Hi,

It looks like the linux-source-4.19 package got corrupt. Please try removing it via apt-get remove, deleting the /usr/src/linux* folders and letting VisualKernel reinstall it.

[support]

Yes, starting from VisualGDB 5.x, you can import the STM32CubeIDE projects directly using the STM32CubeIDE import plugin.

• This reply was modified 2 years, 1 month ago by support. Reason: mentioned new import plugin

[support]

Sorry, could you please post a screenshot of the entire VS window as well. It really shows a lot of important information about the state of the Clang engine (see this explanation). Otherwise, it’s virtually impossible to guess what is going on.

Second of all, does the problem happen with GPIO_PIN_Reset? If yes, please try the following:

1. Try simplifying the expression as much as possible. E.g. “int x = GPIO_PIN_Reset”. Does this still reproduce the problem? If not, is there any specific change between the repro code and the “int x” example that changes the behavior?
2. If the simple case still triggers the problem, does moving right after the preamble (i.e. block of #include<>’s)  change anything?
3. What happens if you add another enum (not just another value to an existing enum) near the place where GPIO_PIN_Reset is defined? Will it trigger the problem as well?
4. If yes, what if you move the newly added enum to the source file that triggers the problem (try putting it before and after the #include<> block)?

[support]

Hi,

We would advise creating a VisualKernel project for the kernel itself  (see this tutorial). First of all, this will allow building and installing the kernel directly from Visual Studio.

Second of all, all you would need to do when creating a new kernel module, is to select “My Kernel is built with VisualKernel” and point it to the Kernel project file. This will automatically handle build paths, versions and source file mappings (see this tutorial).

[support]

Thanks for confirming your license key.

The “Exclude from build” setting works out-of-the-box for MSBuild-based projects only. In order to achieve the same effect with GNU Make-based projects, we can advise one of the 2 workarounds:

1. You can manually use the $(filter-out …) expression combined with ifeq($(CONFIG), DEBUG) to filter out specific files from the source file list (see how this is handled for STARTUPFILES). VisualGDB will preserve your changes to the Makefile, although they won’t be synchronized with the VS-level “exclude from project” setting.
2. Alternatively, simply surround the code in your source files with #ifdef DEBUG (or any other macro used in your project to distinguish debug/release configurations).

[support]

Most likely, the *.xml is not mentioned in the copied file masks. If you could share a screenshot of your settings, we should be able check this and help you find the cause.

[support]

The return code of 0 means that the there was no critical error preventing VisualGDB from launching the tests. You can find out the specific tests that succeeded/failed by analyzing the report file generated by either /output or /vsoutput option (see this thread).

If this doesn’t help, please let us know what exactly you are trying to accomplish and we will try to suggest the best setup for it.

[Author]

Posts