[support]

Hi,

This is not yet possible, but are planning to release a public SDK with some examples in the next few months. Stay tuned!

[support]

According to our records, your trial has expired, so unfortunately we won’t be able to provide any further support unless you purchase a VisualGDB license. Sorry.

[support]

Please let us know the email associated with your VisualGDB order so that we can check your support status and we will be happy to help you.

[support]

Good to know it works. Since building on Linux is a fairly rare use case (and would require slightly different configuration each time), VisualGDB doesn’t support it out-of-the-box, however it is designed to make it relatively straight-forward. We would advise modifying the Makefile to conditionally include a file called linux.mak that would override CC, CXX and other variables set by debug.mak or release.mak.

Since VisualGDB only edits specific statements inside the Makefile and keeps the general structure, this will only need to be done once.

[support]

Hi,

The difference between different revisions for Raspberry Pi toolchains is mainly the compatible SD card image.

This means that we resynchronize it on our side, verify that the all relevant tool and library versions are still the same (normally, only the gcc, libc, libgcc and libstdc++ versions are critical), run a few tests and release it. I.e. it will work out-of-the-box with the specified SD card image. It may also work with a slightly different image (e.g. no desktop included), but unless we explicitly list it as a “compatible image”, we have not verified it on our side.

[support]

Hi,

This looks like a completely different issue, and it also looks like your trial has expired. Please let us know the email associated with your VisualGDB order so that we can check your support status and we will be happy to help you resolve the new issue.

[support]

Sorry, the language standard does not get automatically imported for Keil projects, however you can simply change it via the VS project properties.

We have rechecked the project you previously sent us and it does get imported correctly. If you still run into problems, please send us the updated repro project.

[support]

Thanks for the update. We have fixed the problem triggered with TFS in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2790.msi

The command line log looks like the coverage directories do not get stored in the test container file. Please double-check that you have enabled code coverage for both debug and release configurations in VisualGDB Project Properties. If this doesn’t help, please share your test container file here.

[support]

We have received the logs via the support system.

It looks like VisualGDB running from the test agent still completely fails to launch the tests (it also doesn’t get the VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT variable).

Please try adding the “/v” and “/diag” flags to the VisualGDB command line in TFS (ensure you use build 2789) and send us the updated logs.

[support]

Yes, we have just double-checked the attachment logic on our side and it appears to be working.

[support]

Sorry, it still did not work. We have just rechecked attachments on our side and they appear to be working, so the problem might be caused by your browser.

As a workaround, please try using a file hosting service like Dropbox, or simply send the attachments via our support form.

[support]

Hi,

Thanks for the suggestion. VisualGDB handles the coverage reports on a per-project level (not per-solution), hence merging coverage information from multiple projects behind the scenes could cause weird results (e.g. coverage for subsequent reports belonging to the same project would differ based on the other tests executed during the same session an also the function invocation numbers would be off).

You can somewhat work around it by configuring VisualGDB to keep the raw coverage reports and then running the VisualGDB coverage report generator to build the aggregated report.

Please check the VisualGDB Diagnostics Console for command lines running valgrind2sprof64.exe. Each command line will reference one job file that has the following format:

>[base source directory #1]
[full paths to gcov files]
>[base source directory #2]
[full paths to gcov files]

Please try concatenating multiple job files into one and running valgrind2sprof64.exe on the combined job file. This should produce an aggregated coverage report that can be placed into your project’s coverage report directory in order for VisualGDB to show it.

[support]

Sorry, unfortunately the output you mentioned did not get attached. We also rechecked everything on a clean machine and unfortunately could not reproduce the problem.

In case the VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT variable is not being handled correctly in your setup, we have added a new /diag switch to this build.

Please run it as shown below:

"%VISUALGDB_DIR%\visualgdb" /runtests VisualGDB\Debug\CrossCoverageTest.vgdbtestcontainer /vsoutput:testresult.trx /diag > run.log

The output should contain lines like these:

Downloading coverage files...
Received X11 channel request. Trying localhost:6000...
Directory set #1
        Build-time directory: c:\projects\temp\CrossCoverageTest\VisualGDB\Debug
        Runtime directory: /tmp/cov
Starting coverage report converter: C:\Program Files (x86)\Sysprogs\VisualGDB\valgrind2sprof64.exe --gcov "c:\projects\temp\CrossCoverageTest\CoverageReports\2_6_2019_11_19_00_AM\job.txt" "c:\projects\temp\CrossCoverageTest\CoverageReports\2_6_2019_11_19_00_AM.scovreport"

Please attach the updated output. It should explain what is going on inside the coverage report logic.

[support]

Thanks for sending us the repro. Turns out the project included its own modified versions of the system headers and the Keil IDE included them before the regular headers, while VisualGDB included them after.

We have updated VisualGDB to match the Keil behavior in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2788.msi

Please import the project again.

[support]

Hi,

Sorry about that. Please try the following procedure to narrow down the problem:

1. At the beginning of the source file declare a simple function and check that its name is highlighted: void testfunc();
2. Once you confirm that the name is shown in a different color, move the declaration to the place where IntelliSense doesn’t work. Save the file and confirm that the colors is now not shown.
3. Move the declaration around the source file to find the location after which the highlighting breaks (most likely it will be caused by some special characters that are treated differently by VS and Clang in one of the comments).
4. To fix the problem, simply remove the special character. You can also send us the file causing the problem (just one .c/.cpp file is sufficient) and we will add an automatic workaround for this.

You can convert the encoding for multiple files in the same project using a simple C# program (ensure you backup your sources before):

            foreach (var fn in Directory.GetFiles(@"<dir>", "*.c", SearchOption.AllDirectories))
            {
                var text = File.ReadAllText(fn, Encoding.GetEncoding(<CODEPAGE>));
                File.WriteAllText(fn, text, Encoding.UTF8);
            }

 

[Author]

Posts