[support]

OK, we have reviewed the patches and integrated them into our repository. Thanks again for the pull request.

We have also updated the BSP generator to handle the latest SDKs and are working on an updated BSP.

You can download a preview of the BSP with the latest SDKs here, or simply wait until the next week when we finish running all tests on it and release it officially.

[support]

We agree, however re-writing everything from scratch and maintaining 2 separate copies of every feature would be an overkill for us.

That said, there has been some progress for running .Net apps on MacOS, and a few cross-platform GUI libraries are appearing, so we might be able to release some subset of the functionality on MacOS sooner or later (although we don’t have any specific plans yet).

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

[Author]

Posts