[support]

The behavior changed because v5.3 relied on Visual Studio to ask for the path for the missing files. However a recent VS2017 update changed this to just displaying an error message. As a result, stopping the debugger in a system library that didn’t have sources available resulted in a confusing and annoying error message. Hence we updated VisualGDB to silently ignore the source paths that could not be resolved instead of reporting them “as is”. This eliminated the annoying message during regular debugging scenarios, but broke the rare scenario when the sources are not physically present on the Linux machine and not covered by the path mapping rules, but are still available and can be located manually.

We will consider adding a VisualGDB-level dialog for locating the missing sources and creating a path mapping automatically in one of the next releases. As a workaround, please add a path mapping, or use the global setting to revert to the old behavior.

[support]

Thanks for the clarification. Indeed, in this case the sources won’t be auto-downloaded as they won’t be present on the gdb machine.

As a better alternative to disabling the new behavior, please consider adding a path mapping rule via the path mappings button in the GDB Session window to link the source path reported by gdb with the actual location of the source files on the Windows machine.

[support]

Thanks for the log file. Normally, VisualGDB should have automatically downloaded the remote file to a temporary folder if it could not map the path using the regular rules.

We have added more internal logging to this logic in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2736.msi

Please try reproducing the problem and share the updated diagnostic log.

[support]

Thanks, we have rechecked this and indeed it looks like our sample project wrappers don’t include this file. We will run a few internal tests with this and will try to automatically include this file in the next releases of our STM32 package.

[support]

Thanks for the clarification. How do you import those examples into VisualGDB? Are you using the New Project -> Samples -> Use STM32CubeMX Examples setting, or a different mechanism?

[support]

Hi,

The examples like “Audio Record and Playback” come directly from ST, so we are usually not able to provide much insights into them (you might be able to get some hints from ST via their support forums) . That said, if it looks like VisualGDB is not automatically importing a file that is a part of the example, please let us know the exact example name and the device name and we will double-check this.

[support]

Thanks for confirming this. The issue might be caused by a recent change in the VisualGDB’s behavior when it cannot compute the full path to a source file on the windows side.

In version 5.3, VisualGDB would report the original path as shown by gdb and Visual Studio would show a prompt allowing you to locate the file manually. In one of the recent VS2017 updates, Microsoft changed their logic to display an error message instead, so we updated VisualGDB to simply ignore the frames referencing non-existing files.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2733.msi

It will show the details about the frames with missing source files via View->Other Windows->VisualGDB Diagnostics Console. If you could share the output from the diagnostics console, we should be able to see what is going on and fix it.

You can also disable the new behavior via Tools->Options->VisualGDB->Common->Debug->Hide Missing Source Files.

[support]

No problem. The option is located under Embedded Frameworks -> Framework Configuration -> Profiler -> When running without debugger.

If you don’t see this setting, please update to VisualGDB 5.4 Beta 2 and install the latest version of the profiler framework via the VisualGDB Package Manager.

[support]

No problem. Let us know if you encounter any further issues and we will be happy to help.

[support]

Hi,

Sorry, this isn’t supported fully automatically, however there are a few workarounds.

First of all, you can configure the profiler framework (via the Embedded Frameworks page of VisualGDB Project Properties) to ignore semihosting calls when the debugger is physically not connected.

Second of all, please consider selecting the framework source files in Solution Explorer and setting the “excluded from build” flag (don’t confuse it with “Exclude from project” command). This will effectively exclude the semihosting-related logic from the release build.

[support]

Just a separate UART port won’t be sufficient for live variables. Some logic on the BMP side would need to handle the “read memory at address XXX” commands via this port, do the actual reading via JTAG/SWD and return the result.

Alternatively, we can add an API similar to the custom real-time watch that will let your program report arbitrary values via a connection such as a COM port, so VisualGDB will plot them.

[support]

Hi,

There is no VisualGDB-specific command for this, however you might be able to use the mon flash erase_address command via the GDB Session window if the Espressif’s port of OpenOCD supports it properly (we haven’t tested it yet, sorry).

[support]

Hi,

This is actually supported through a different mechanism – custom per-user variables (see this tutorial and also host aliases). You will still need to check in the .vgdbcmake file into source control, but you won’t need to hardcode any per-user settings there. If this doesn’t work, please let us know and we will try to suggest a better way to achieve this.

[support]

Hi,

Yes, the Linux edition includes all of the features of the Embedded edition.

You can find a list of VisualGDB editions and features here: http://visualgdb.com/buy/

[support]

You can try using the Synchronized Directories page of VisualGDB Project Properties (Custom edition and higher). It allows linking a specific Linux directory to a specific Windows directory and defining the exact files that will be synchronized and the conditions for it.

However, the “go to definition” will only work for files that are a part of the project (VisualGDB cannot find a definition of a function in the .cpp file unless it knows the flags the file is built with so it can fully parse it). The easiest way to fix that would be to import the SDK sources into another VisualGDB-based project in the same solution (it doesn’t have to be fully buildable; as long as the source files are included into it and you specified the correct header directories, or let VisualGDB discover them with header discovery, it will be able to index the file contents).

[Author]

Posts