[support]

Hi,

Sorry for the delay. We have added support for using the SSH console when not debugging to the following build: VisualGDB-5.5.5.3573.msi

The commands for opening the console appear in both the View menu (for the startup project) and the context menu for a specific project in Solution Explorer.

[support]

Hi,

Please use the “Warn About Detached Files” option. You can find the full path to the option here: https://visualgdb.com/settings/

Also, feel free to try this build: VisualGDB-5.5.5.3573.msi. It will suggest automatically adding a path mapping rule for automatically downloaded remote files.

[support]

Hi,

Please try updating to VisualGDB 5.5 Preview 4.

[support]

This looks like the some issue between the VisualGDB’s project node and the Visual Studio Solution Manager. Please try closing the Solution, deleting the .vs subdirectory and opening it again.

If it doesn’t help, please check if the problem happens with a newly created project as well.

[support]

Yes, please consider creating a project manually as shown here: https://visualgdb.com/tutorials/arm/legacy/

[support]

Good to know it works. BTW, you can set mappings for arbitrary path prefixes, e.g. the following mapping should cover all the necessary files:

/var/volatile/tmp/VisualGDB/c/TrollSource => c:\TrollSource

 

[support]

Hi,

This error happens because the tests use a separate pipe (created with mkfifo) to report structured tests outputs to VisualGDB, and telnet doesn’t allow easily multiplexing multiple streams.

Does your target have mkfifo + netcat installed? If yes, please try checking if you can launch netcat in the background over telnet and let it forward a mkfifo-ed pipe to TCP. If yes, we can extend the custom target interface to allow running unit tests (your implementation would need to “open” a remote pipe and return a .Net Stream object corresponding to it, that will be independent from the regular telnet output).

[support]

Hi,

No problem. Although this is not documented yet, VisualGDB exports a public interface for reading the coverage report files. You can try it out as shown below:

1. Create a new C# project and reference the VisualGDBCore.dll assembly.
2. Create an instance of the CoverageReportReader class. Pass the path to the report file as the first argument, and null as the second one.
3. Use the AllFunctions property to get information for all functions.
4. Call the GetFunctionsInPotentiallyMatchingFiles() method with the name of a source file to get detailed line-by-line coverage information.

You can use Visual Studio’s IntelliSense and Go-to-Definition command to see the properties and methods of the CoverageReportReader class.

[support]

Good to know it works. Most likely, the files are downloaded because the paths reported by gdb don’t match the paths expected by VisualGDB. This would happen if the target had symbolic links in some directories.

You can troubleshoot it by checking the GDB Session window for the path reported by GDB and then setting a mapping via VisualGDB Project Properties -> Path Mapping.

[support]

Thanks for checking this. Most likely, the problem happens because VisualGDB fails to create a temporary terminal (pseudo-tty) to avoid mixing the output from the program with the output from gdb.

The easiest way to work around it would be to use gdbserver on the target (you can configure it by selecting the “gdb stub” mode in the VisualGDB Project Properties -> Debug Settings). This will eliminate the need to create a virtual terminal and should work around the problem.

[support]

Hi,

Strange. Just to double-check, are you able to run the program under gdb manually? I.e.:

gdb /mnt/TrollSystems/_Applications/ConTroll21_S6K2/ConTroll21_S6K2_Lin.exe
b main
run

If yes, does it change if you run it as “gdb –interpreter mi <path”> instead of just “gdb <path”> and use the “-exec-run” command instead of “run”?

[support]

Hi,

Please refer to the following page for detailed overview of VisualGDB’s IntelliSense engines and instructions for switching them: https://visualgdb.com/documentation/intellisense/

[support]

Sorry, this looks like something specific to the particular mbed project/board and not to VisualGDB, and hence is not under our control. Please consider the following resources for help on issues that are not specific to VisualGDB:

• Mbed forums to discuss issues specific to mbed
• StackOverflow for generic programming questions

Also if you can confirm that the problem does not happen when using a command-line debugger (e.g. gdb), but happens with VisualGDB, we can help you understand the differences and configure VisualGDB to match the command line gdb behavior.

[support]

Thanks for confirming your license status. We have linked your forum account to the new key.

We have also updated the VisualGDBExtensibilityExamples repository to reference the correct assembly out-of-the-box.

• This reply was modified 5 years, 7 months ago by support.

[support]

Hi,

Please try deleting the %LOCALAPPDATA%\VisualGDB\Python* folders, updating to VisualGDB 5.5 Preview 4 and then install Python 3.x via the VisualGDB Project Wizard. This will get the correct version of Python with pre-installed mbed scripts.

[Author]

Posts