[support]

As discussed per email, this is the limitation of the TrueSTUDIO GDB server. Using a GDB server that is not restricted to TrueSTUDIO is the solution.

[support]

Hi,

Please ensure that the the DLL being loaded contains symbols. Please run the ‘info shared’ command in the GDB Session window and paste the output here. Please also run the ‘info sources’ command to see which source files are listed in the currently loaded symbols.

[support]

Hi,

Thank you for your feedback. We have added support for build variables in custom directory mapping to the upcoming v3.1 release.

[support]

Hi,

Yes, using OpenOCD is possible, however we currently do not provide a step-by-step tutorial. Please refer to community-hosted instructions on setting up GDB with OpenOCD to get the OpenOCD arguments and GDB starup commands.
Please use the VisualGDB project wizard or the VisualGDB Project Properties window to provide those commands to VisualGDB.

[support]

Hi,

We cannot really speak for the competitors here, so I will only list the key features of VisualGDB that are relevant to embedded systems and are intended to make your development as comfortable as possible:
1. The MSP430 projects can be created easily by simply selecting your device type in the MSP430 wizard. All GCC flags, gdbproxy command line settings, etc. are configured automatically.
2. The MSP430 hardware registers can be easily viewed using the special Hardware Register Viewer window.
3. You can see the interaction between VisualGDB and GDB using the GDB Session window. This might be useful when diagnosing compatibility problems with third-party GDB stubs.
4. You can easily change various project settings via the VisualGDB Project Properties context menu command. The properties editor is easy to use and includes a quick search option:

5. VisualGDB automatically updates the makefiles instead of regenerating them. Thus you can always do your fine-tuning (e.g. change various GCC flags) or add new targets, while VisualGDB will keep your source file list in sync.

Update: click here to learn more about VisualGDB features

[support]

Hi,

Are you using clang to compile your code? Clang has a known debug information generation bug that prevents VisualGDB from obtaining a reference to the tree nodes. Could you please provide us with the errors listed in the “GDB Session” window?

[support]

Hi,

You are probably using the old VisualGDB 2.x release that is no longer available for new trials.
Please download the latest VisualGDB 3.0 trial from http://visualgdb.com/download

[support]

Hi,

“–interpreter mi” enables a special “machine interface” mode which is required for VisualGDB to understand its output.

We could offer 2 workarounds for this bug:
1. We could add a special “auto-ping” flag that will cause VisualGDB to repeat pinging GDB if a command takes too long to respond.
2. We could add an option to disable the ‘info target’ command for a certain project. Disabling it will affect the main module name in the Threads window and module name detection in Call Stack window.

Please let us know what’s the best for you.

P.S. Please try building the latest GDB from source code. This should not take too much time (../gdb-version/configure && make -j<# of CPUs>), but will probably solve your problem in a much cleaner way.

[support]

Hi,

Thank you for running the tests and sorry for the confusion between “target” and “info target”.
This starts looking more like a bug of your GDB or a deep SSH protocol bug. Could you please try reproducing it with another SSH client (e.g. logging on from a Linux machine or using a Windows SSH client that is not based on libssh2)?
Could you also try a different version of GDB?

P.S. This is normal that the ‘timeout’ dialog is not shown when you are reproducing things manually. VisualGDB only shows it when it’s in full control of the GDB session and knows when to expect a reply. This does not pertain to manually launched GDB sessions.

[support]

Hi,

Sorry for the delay, unsuccessfully tried to reproduce it on our side. This looks like some strange SSH protocol bug. In order to investigate it further please try the following:
Once debugging has been started please go to the SSH session window, click on the hyperlink to start a session, then run GDB manually in the session:

gdb

then set a breakpoint manually, run the program and try issuing the ‘target’ command manually:

b main
r
target

Please let us know if the output of the ‘target’ command comes normally, or if you experience the same problem in the manual mode. If in the manual mode the problem does not reoccur, please rerun GDB in the MI mode:

gdb –interpreter mi

Although GDB output will look differently now, it will still accept normal commands. Please try running the same 3 commands to see if the ‘target’ output is incomplete.

If you manage to reproduce the problem in the manual mode, please click at the console symbol inside the GDB session window. A multi-tabbed SSH client will be launched. Please open 2 tabs, try reproducing the frozen ‘target’ command in one tab and then see if typing anything in another tab affects the first tab.

[support]

Hi,

Oops, sorry for that. Please provide us with the following information to pinpoint your problem:
1. Does the problem occur on every debug session? If not, how frequently does it occur?
2. Does the “timeout” dialog automatically disappear after 1-10 seconds? If this is a bug of LibSSH2, we have a safety mechanism that should automatically resolve such hanging within 1-10 seconds.
3. Does invoking “info target” manually via the SSH Session window cause the same bug?

[support]

Hi,

Currently this is not possible directly. You can put a breakpoint at the end of the main() function to achieve a similar result.
Using scanf() or cin should normally work. Please send us an archive with an entire test project (including the source code and the Visual Studio project files). If this is a bug of VisualGDB, this will help us to reproduce and fix it.

[support]

Hi,
Please go to Visual Studio Configuration Manger (click on the debug/release switch on the toolbar) and remove the “build” flag for the projects you don’t want to build.
Note that you can create as many solution configurations as you want all having different project sets enabled.

You can also configure Visual Studio to prompt before auto-building the projects when you start debugging.

[support]

Hi,

Normally the Python include files are located in a Python-version subdirectory (e.g. /usr/include/python2.7/Python.h). Thus you need to add it to additional include path.
This can be done by setting the INCLUDE_DIRS variable inside flags.mak. E.g.:

INCLUDE_DIRS := /usr/include/python2.7

If you are using a cross-compiler, the path will be:

CROSS_SYSROOT := C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot
INCLUDE_DIRS := $(CROSS_SYSROOT)/usr/include/python2.7

[support]

Thanks for the kind words. We do our best here at Sysprogs to make complex debugging scenarios easy and enjoyable.

As for the cross-compiler, both options have pros and cons:
• Building big projects with a cross-compiler is usually faster, as your computer is much faster than the Raspberry PI box. However, it will require synchronizing includes/libs and might cause strange bugs if the libraries inside the cross-compiler and on the Raspberry PI get out of sync.
• Building and running GDB directly on Raspberry PI should work out-of-the-box for most cases, but it may become annoyingly slow for big projects with many source files.
• If you are building an app that comes with a configure script that should run on Linux, you cannot use the cross-compiler unless you want to set the MSYS environment manually (which will still impose some limitations).

Bottom line, VisualGDB fully supports both options, the choice is yours depending on what’s more important to you…

[Author]

Posts