[support]

Hi,

The “no source file” problem usually happens when the debugged executable is missing the debug symbols or the source file belongs to a .so library that is not loaded yet.

Please try checking the list of source files known to gdb by running the “info sources” command. Perhaps some symbolic links in some directories result in a different path for that file?

[support]

Hi,

This looks like a bug. Could you check the GDB Session window to see if VisualGDB is issuing the -break-after command properly to communicate the hit count to gdb?

[support]

Hi,

Are you using semihosting in your programs? The way semihosting works would cause the program to stop if a debugger is not attached. Please try making the calls to printf() and other semihosting-related functions conditional so that they don’t trigger in the release configuration.

[support]

Hi,

Sorry, generating warnings in this case would require modifying the compiler, and we would rather not risk breaking things with that. The only workaround we could suggest is to quickly use the Memory Explorer window to double-check the sections for specific functions of interest.

[support]

Hi,

Sure, we will add this to the next maintenance release of VisualGDB 5.2.

[support]

Hi,

This could be caused by VisualGDB setting some implicit breakpoints and using the one and only hardware breakpoint of ESP8266. Could you check this by entering the ‘info breakpoints’ command in the GDB session window and seeing if there are any breakpoints not explicitly set by you? If yes, does deleting them via the ‘delete’ command help?

[support]

Hi,

Yes, we’ve encountered some troubles with mbed 5.2.1 requiring bootloader on some targets and a few minor build issues. We will be publishing a beta version of the mbed 5.2.1 BSP in a few days. It won’t work out-of-the-box on 100% targets, but will be usable otherwise.

[support]

Hi,

We don’t have a tutorial specific to odroid, but most of the steps for Raspberry Pi and other boards should be the same.

[support]

Hi,

The library should be added automatically as long as you reference the corresponding project from your main project. Perhaps you missed that step or something went wrong and the reference was not handled correctly?

[support]

Hi,

Yes, sorry, it’s currently a limitation of the Clang IntelliSense engine. We may support it in further versions, but currently it won’t work unless you switch back to the native VS IntelliSense.

[support]

Hi,

The easiest way to achieve that would be to disable the normal source uploading and then do it via a custom pre-build action after running your script. If this does not work, please let us know.

[support]

Hi,

The USB communication device example only supports the CDC (communication device) class. The mass storage class requires completely different source files.

Please update to the final release of VisualGDB 5.2, then update your STM32 BSP to the latest version. Then you will be able to select “Show STM32CubeMX samples” on the Sample Selection page and pick the “FatFS_USBDisk” example that shows the use of the mass storage class.

 

Regarding the ‘import recursively’ command, it’s only supported in the Custom edition and higher. If you are using the Embedded or Linux edition, you can add the files manually (one directory at a time). The header discovery will still work as shown in the tutorial.

[support]

Hi,

If the .so library is built by a VisualGDB project, you can simply reference the project via Add->Reference. If not, you would need to manually add the following command to GDB startup commands:

set solib-search-path <directory on Windows where the .so file is located>

[support]

Hi,

Unfortunately currently there is no such trick for the .hpp file, but we will look into handling this automatically once the final v5.2 is out (beginning of the next week). Right now VisualGDB simply checks for the timestamp of the main .cpp file, but we could easily make it check the relevant file contents.

One major optimization of v5.2 is that code completion (when you type code or press ctrl-space) should work even while the 10-second ‘parse – check’ phase is active, so the 10-second delay should only affect advanced colorization of newly typed text, but not most of the normal functionality. Could you confirm that it actually works for your project?

[support]

Hi,

You can tell gdb where to look for your .so symbols using the set solib-search-path command. Normally VisualGDB should do it automatically as long as your application project references the .so project.

If it is referenced and the .so library is not found, please let us know and we will investigate and fix this.

[Author]

Posts