[support]

Hi,

The Folder View is implemented by Visual Studio itself and not VisualGDB. Hence, the advanced VisualGDB functionality (Advanced IntelliSense, non-intrusive debugging, custom steps/configurations) indeed won’t work in it.

[support]

Hi,

We normally advise using the latest Visual Studio (2022), although most VisualGDB functionality works the same with all supported VS versions.

[support]

OK, we have updated both the regular OpenOCD and the ST fork. It should now be equivalent to the version used by STM32CubeIDE.

You can update conveniently via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

OK, we have just released an updated ESP32 toolchain that includes ESP-IDF 5.1 and fully supports ESP32-C6. Feel free to update to it via VisualGDB Package Manager.

We have also published a tutorial on debugging the ESP32-C6 here: https://visualgdb.com/tutorials/esp32/esp32-c6/

[support]

Hi,

It looks like the error is caused by the differences in the way gcc and clang handle the __VA_OPT__ syntax. ESP-IDF code was never tested with Clang, so it makes sense that it would trigger unexpected errors.

You can work around it by patching the definition of ESP_LOG_LEVEL_LOCAL() in esp_log.h as follows:

#ifdef __SYSPROGS_CODESENSE__
#define ESP_LOG_LEVEL_LOCAL(level, tag, format, ...)
#else
#define ESP_LOG_LEVEL_LOCAL(level, tag, format, ...) do {               \
        if ( LOG_LOCAL_LEVEL >= level ) ESP_LOG_LEVEL(level, tag, format, ##__VA_ARGS__); \
    } while(0)
#endif

The __SYSPROGS_CODESENSE__ macro is only defined by Clang IntelliSense, so it won’t affect the actual build, but will prevent IntelliSense from trying to parse unsupported syntax.

 

[support]

Hi,

Most likely the Clang cache got corrupt. Please try closing the solution and deleting the CodeDB subdirectory (normally inside the .visualgdb subdirectory).

[support]

Hi,

Thanks, this looks great! Our parser indeed only handles about 90% of the registers that are defined in a consistent way (getting it to 100% would require exponentially increasing amount of workarounds and special cases). However, this looks like a solid fix that covers several registers at once.

We will review the patches this week and will post an update here once done.

[support]

Hi,

Thanks for the update. Looks like we actually found the issue. The path from the Windows file properties is identical to the one shown in the error message, however because you are using the Parallel Studio compiler instead of GCC, it outputs the error messages in a slightly different format. So, VisualGDB ends up treating the line number as part of the path (Test.cpp(9) instead of just Test.cpp).

You can fix it by manually setting the GCC/DetailedMessage element in the <VisualGDB Directory>\Rules\RegularExpressions.xml file to:

^([^:]+|[a-zA-Z]:[^:]+|[a-zA-Z]:/[^:]+)\(([0-9]+|)(, [0-9]+|)\): (error|fatal error|internal compiler error|warning|note|Error) *:(.*)$

If the regex doesn’t cover some other messages, you can use debuggex.com to quickly test it out and tweak the regex to cover all cases.

Note that this will affect all projects and will stop VisualGDB from parsing the GCC messages correctly. If you would like to change it only for one project, you can use this build [VisualGDB-6.0.1.4882.msi] and save the attached BuildMessageRegexes.xml file to the project directory and add the following element into the .vgdbsettings files directly under VisualGDBProjectSettings2:

<BuildMessageTemplateFile>BuildMessageRegexes.xml</BuildMessageTemplateFile>

This will override the DetailedMessage element only for the projects with edited .vgdbsettings files, while using the regular regexes for all other projects (note that most project types use separate .vgdbsettings files for Debug/Release configurations and also libraries use separate .vgdbsettings files from executables).

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please find the answers below:

1. The delays caused by -stack-list-frames and known workarounds are described on this page. You can also open it by clicking “read more about unresponsive GDB commands” link in the timeout window shown on the screenshot.
2. The CPFver5_vgdb_LOCATION variable is set automatically based on the PATH argument passed to register_imported_project(). If you would like to update the relative path to the imported project, please consider editing the statement accordingly.

Also, the easiest way to make the imported project reusable is to create the initial VisualGDB project already in the imported project directory. You can do it using the checkboxes shown below:

Attachments:

You must be logged in to view attached files.

[support]

Hi,

VisualGDB uses the “//!” syntax to generate Doxygen comment templates. It should work just fine, as long as you are using the Clang IntelliSense.

[support]

Hi,

The demo project will not build in our environment because it references a toolchain that we do not have (source /opt/intel/parallel_studio_xe_2020.4.912/psxevars.sh intel64;) and multiple other files from your machine involved in managing this toolchain. Hence we cannot advise anything based on it – it fails much earlier with a completely different error message.

Also, the file synchronization settings on the first page of VisualGDB Project Properties do not make sense – they map the $(ProjectDir) to $(ProjectDirLinux) that you manually defined as “/” via User Variables page. Unless you are manually uploading the project into the root directory on the Linux side (that shouldn’t be the case), the path mapping is not correct and will not work.

We can help you if you could provide:

• The full build log showing the error message.
• The screenshot of the error you get when clicking on the error message.
• The exact path (as seen from the Windows machine) of the test.cpp file that you expect to open when you click on the message.
• A screenshot of the Path Mapping page. For testing, please use hardcoded paths instead of $(BuildDir) there. Once you get it working, you can switch back to using $(BuildDir).

 

[support]

Hi,

Thanks for the detailed repro information. Please find the detailed explanation below.

The problem happens because the Intel compiler you are using reports the errors using relative paths:

Test.cpp(9): error: expected a ";"

When VisualGDB encounters, such a message, it first checks the build log for “entering directory <…>” messages from GNU Make, and it there are none, it defaults to the directory of the .vcxproj file. Hence, Test.cpp gets mapped to <Directory of .vcxproj file>\Test.cpp.

If you would like to map it to N:\6731_OMFV\SHMUEL\rdpMRS\rdp\dsg_cmp\src\test.cpp instead, you can set VisualGDB Project Properties -> Path Mapping -> Default Windows Directories -> Relative Paths (bottom option on the page) to N:\6731_OMFV\SHMUEL\rdpMRS\rdp\dsg_cmp\src.

Please also remove the $(RemoteSourceDir) => $(BuildDir) mapping, as it may interfere with translation of other messages.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The built-in debugging interface was originally introduced in ESP32C3, hence VisualGDB calls it “ESP32C3 debug interface”. If it was auto-detected by the USB ID as shown on the screenshot, it should work just fine.

[support]

Hi,

Looks like the video is private and won’t download without a login (that won’t work on our isolated repro VMs). Please consider sharing it publicly as described here or use a different service that does not require logging in.

If you do not wish to share the steps publicly, please consider placing the video into an encrypted archive, and sending the password via our support form.

[support]

Thanks, we will look into it and release a repackaged toolchain within the next 2-3 weeks.

[Author]

Posts