[support]

Hi,

Sorry, VisualGDB doesn’t provide any hooks that are executed when a library is loaded, however you can work around this as follows:

• If you are debugging directly on the target, simply strip the symbol information from the libraries you don’t want to debug using the strip command (make backups in case you need the debug information later).
• If you are debugging with a gdbserver, setup a directory on the gdb machine with the symbols you want to load (copy the updated symbol files there via custom actions) and ensure no other symbol files get there. Then replace the solib search path by with a path consisting of only that directory. Hence gdb will locate the libraries you want to debug and will skip the rest.

You can also try indexing your symbols as described here, although in our tests we couldn’t get any significant performance improvement, so we decided not to do it automatically.

[support]

Hi,

Strange, perhaps the reply did not get posted due to corrupt cookies or some proxy issues. Either way, good to know it works. If you encounter any further problems, don’t hesitate to let us know and we will help.

[support]

 

Hi,

Normally just pointing it to a header file with multiple #include-s should do the trick. You can double-check if it’s being included by defining a macro inside the file (e.g. #define TEST_PCH) and then checking for it in your code:

#ifdef TEST_PCH
#error test
#endif

The IntelliSense should then highlight the “test “error (it won’t affect compilation). If the macro gets propagated properly, but the IntelliSense is still slow, please let us know what exact operation is slow, attach a quote from the Clang IntelliSense Diagnostics console and a screenshot of the timing report (timer icon at the top right corner of the navigation bar) and we can help you optimize your IntelliSense experience.

[support]

Hi,

It looks like something is preventing the git command to clone the ESP-IDF repository. Please check the output of the git command shown in the progress window for clues. If you are not sure, please post it here and we can help you understand it.

[support]

Hi,

Thanks for explaining this – it makes sense. Good to know you have found the workaround. Let us know if you run into further problems and we will be happy to help.

[support]

 

Hi,

Yes, that might work, although due to differences between the VC++ and the gcc compiler, some features might still not be supported properly.

[support]

Hi,

Sorry, we only provide technical support to registered users of our paid products. In order to keep on receiving technical support, please let us know the email address associated with your license.

[support]

Hi,

Please let us know the email associated with your license key so that we could check your support status.

[support]

Hi,

Sorry, the VisualGDB semihosting console only supports UTF-8 as it has become a de-facto standard encoding for all non-Latin characters. Would switching the encoding of your source files to UTF-8 be a reasonable workaround?

[support]

Hi,

Looks like you are missing the –interpreter mi argument before $(TargetPath). Specifying it (and also configuring VisualGDB to use the ‘continue’ command to start the session) should get it to work.

[support]

Hi,

Yes, please try referencing the bootloader project via Project Dependencies (not the regular Project References). This should affect the project build order without changing any actual build-related flags.

[support]

Hi,

Sorry, the native Visual Studio IntelliSense is outside our control. Please contact Microsoft regarding their plans for C++17 support/gcc compatibility.

That said, the recent versions of the Clang IntelliSense engine contain optimizations that improve the performance for huge projects (e.g. the IntelliSense-only PCH files), so you should be able to get reasonable performance out of it. Feel free to let us know if any specific scenarios are slow and we will help you set it up.

[support]

Hi,

Normally selecting a “computer used for building and debugging” will affect the following functions:

1. The target machine for uploading the sources [not overridable, but can be disabled and replaced with a custom action]
2. Machine where the build command is run [overridable]
3. Machine where the debug command is run [overridable]

You can override #2 and #3 by setting the “Allow choosing build/clean/debug command hosts independently” checkbox on the Linux Project Properties page in VisualGDB Settings and then manually picking the host in the build command on the Build Settings page and/or the gdb command on the Debug Settings page.

Another option would be to disable the automatic source synchronization and synchronize it instead via a pre-build action (transfer a directory to a remote computer).

Please note that both options require the Custom edition or higher. If you are using a lower edition, you could work around by creating 2 project configurations (one for transferring the files and another one for building), although it would be less convenient than a 100% automatic setup described above.

[support]

Hi,

Please let us know the email associated with your license key so that we could check your support status.

[support]

Hi,

This looks like an error in the J-Link gdb server (JLinkGDBServerCL.exe). Please contact Segger support regarding this as we don’t have access to the Segger GDB stub internals and are not able to troubleshoot its crashes.

The memory we mentioned is used by the Semihosting Framework – it uses a part of the on-chip RAM to store the semihosting output (the debugger will read it in the background without stopping the target). This should not crash the J-Link gdb server, as all Fast Semihosting-related logic is handled by VisualGDB directly.

[Author]

Posts