[support]

No problem. Let us know if you run into any issues and we will be happy to resolve them.

[support]

Hi,

This is to be expected. VisualGDB relies on various Visual Studio services for displaying the GUI, managing the settings, etc. Hence a corrupt Visual Studio installation could indeed trigger strange errors in those services, interfering with VisualGDB functionality. Repairing both Visual Studio and VisualGDB installation is indeed the recommended way of solving this.

[support]

Clang IntelliSense fully supports renaming symbols. Simply right-click on a declaration and select “Rename” to rename it.

VisualGDB also supports C#-style renaming where you can edit the declaration name in-place and use the Quick Actions menu (Ctrl-. keyboard shortcut) to rename all references.

[support]

No problem, we have added experimental support for preprocessing linker scripts in MSBuild projects to the following build: VisualGDB-5.5.2.3415.msi

You can enable linker script preprocessing via VS Project Properties -> Linker -> Linker Script. You can use other properties on the same page to define additional preprocessor macros/include directories and to control whether the default C/C++ ones get automatically inherited.

Let us know if you have any feedback on the new feature and we will be happy to make VisualGDB even better.

[support]

Thanks for finding this out. We have updated VisualGDB to create the TestMethod element as well (VisualGDB will only set the “name” attribute, as others are not relevant to the VisualGDB test logic). Please try this build: VisualGDB-5.5.2.3414.msi

If it still doesn’t work, please try manually adding other attributes present in the regular .trx file (e.g. codeBase, adapterTypeName) and let us know which combination of them fixes the problem, so that we could update VisualGDB to set them to some dummy values.

[support]

Please try updating to the latest preview build of VisualGDB: VisualGDB-5.5.2.3413.msi

The internal structure of the Teensy core has recently changed and may no longer work with the older VisualGDB versions.

[support]

Thanks for checking this. It looks like some minor structural differences between the .trx file generated by VisualGDB and the files expected by the Jenkins tools are interfering with the parsing.

Please try the following steps to diagnose it:

1. Create a dummy C# unit test with the MSTest framework. Run it with MSTest.exe and obtain a .trx file.
2. Update your Jenkins setup to use a fixed .trx file generated in step 1 instead of the one produced by VisualGDB.
3. Check if the test results are imported correctly. If not, double-check the Jenkins setup.
4. If the .trx file produced by MSTest works, but the one produced by VisualGDB doesn’t, try eliminating the differences between them. E.g. change the test names in one of the .trx files to match the other one and then try adding the elements present in another .trx file until Jenkins starts recognizing it.

Once you determine what part of the .trx file is interfering with Jenkins, please let us know and we will update VisualGDB to generate it in a way expected by the Jenkins tools.

[support]

Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/

[support]

Hi,

Due to privacy reasons, we do not post sensitive license-related information on the forum. Please contact our technical support for all licensing-related issues.

[support]

Hi,

As the error message suggests, please try checking the Output window for details. It will show a detailed build log including the lines that were not directly recognized as clickable error messages.

[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.

 

[Author]

Posts