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

[support]

Hi,

Thanks for the suggestion. COM port aliases look interesting, although, based on a very brief research, it doesn’t look like a very frequently used feature.

Hence, we would like to hear more feedback from other users first. If anyone is using COM port aliases and would benefit from VisualGDB displaying them (as opposed to entering the COM port manually), please feel free to comment in this thread.

[support]

Hi,

Based on what we see, it looks like you have several files with very similar paths, and some mapping rules that look almost correct, but are off in some very subtle way.

In order to fix it, you would need to double-check all the paths and mappings.

First of all, please remove all secondary projects from Solution Explorer, so you only have 1 project )it will only affect the .sln file). This will ensure you are changing the settings for the same project that is generating the error messages (otherwise the settings will not change anything). Then, please share the screenshots of the following:

• The exact error message shown when you try to open the file.
• The exact message in the build log (VisualGDB Output -> Build -> Log, not the error list).
• The Project Settings, Synchronized Directories and Path Mappings pages of VisualGDB Project Properties.
• Solution Explorer showing only one project in the solution.

Once you get it working with just one project, you can try restoring the .sln file from the backup, or re-adding the projects manually. If the problem starts happening after adding a specific project, please let us know and we will advise you on the troubleshooting steps.

[Author]

Posts