If you've found bug/problem in WinGDB, then please contact us.

There is diagnostic mode. If you would like to create log file, then please go to WinGDB Preferences and enable logging ( more info you can find here ), then run debug session once again. On disk there should appear log file, remove from it all data you don't want to share and please send it to us.

More about product registration you can read here.

Documentation regarding Android you can find here. There is "Development for Android system" section.

Here are listed known problems which can arise during development for Android system.

• GDB version containing bug(s)
  Some versions of GDB contain bugs - check known problems section to ensure you don't use one of them. In such case change GDB to a newer or an older one. one.
• Old version of SSH
  The long delay between commands and responses suggests a network communication problem caused by a bug in a SSH server. This concerns only very old versions of OpenSSH (< 4.4). Upgrading the OpenSSH daemon on target machine to a newer version solved the problem in all cases we know so far.
• Android Emulator
  The Android emulator included in SDK is quite slow and unfortunately this is noticeable while debugging. For more info check trouble-shooting section concerning Mobile Edition.

In case you experience problems with the download with Opera (file extension is changed from .msi to .exe) please look here.

There are many environments and toolchains for embedded development based on GNU tools. Starting from 1.3, WinGDB supports CodeSourcery G++ Lite toolchain for ARM Linux. Expanding to other platforms / toolchains is planned, however it depends on the demand from our (potential) users. So, if you would like to use WinGDB with another platform or toolchain, please contact us. Also our ability to implement and support particular configuration depends on our access to hardware and tools. Therefore, popular hardware (mainly ARM) and free toolchains are preferred.

WinGDB 1.3 has been successfully tested with OpenOCD 1.3 and GNUARM tools on ARM7 LPC2000 family of microcontrollers. For other platforms and toolchains, the situation is similar as above. First of all you have to try it yourself, chances are that it will work in your configuration also. If not, please contact us.

WinGDB has not yet been tested with any such device.

In theory, WinGDB can support every language that is supported by both Visual Studio and the backend (for now, only GDB). You can extend the language support of Visual Studio adding Language Packages. Also there exist GDB variants for many languages. However, current WinGDB versions are tested only with C/C++ programs.

WinGDB is being tested under Visual Studio 2005, 2008 and 2010. These are supported versions. However, some functionality may work under Visual Studio 2003 as well. This configuration is not supported at the moment. However, we might consider implementing it, if there is significant demand.

WinGDB supports all editions of Visual Studio except the Express editions. The Express editions lack extensibility support which is required.

WinGDB does support GDB 6.x/7.x, although current version of WinGDB is being tested mostly under GDB 6.8/7.x. It's safe to use this (or newer) version and we strongly suggest it. Most of features work on older versions also. However, older versions of GDB have serious drawbacks e.g. in handling breakpoints with multiple locations. Currently WinGDB utilizes the "pending breakpoints" feature if available, else it will be emulated if possible.

WinGDB uses remote shell to control the debugger, SCP for transferring files and SFTP for remote file system access. It supports both plain and keyboard-interactive authentication.

Yes, there is a console window emulating xterm-color terminal. It's not perfect at the moment, but works nice with popular SLang and curses programs like mc. Also there is an idea to write special X-server with debugging features for WinGDB. It's far future however.

To check whether your debugger supports visualizers run below commands on machine where GDB is located:

gdb --interpreter=mi
-list-features

The output should be similar to this one:
^done,features=["frozen-varobjs","pending-breakpoints","python"]

Visualizers are supported only by debugger which does return "python" among list of features. You need at least GDB 7.0. Sometimes it doesn't have python support enabled, then you can enable it in sources and rebuild GDB on your machine.

From our experience gained during many years of work in software companies, it turns out that such situation is quite frequent nowadays. Let's imagine a company which is developing their product in C++ and they are porting it from Windows to Linux. Or maybe they are developing a new multiplatform product. Usually the developers work on Windows most of the time, and Visual Studio is already the standard development platform on this system in that company. Linux versions are being built from common source code base and tested separately. However, annoying Linux-only bugs crawl in, and someone has to deal with them. It consumes a lot more time than fixing regular bugs which are reproducible on Windows. That is because a lot of unfavorable circumstances arise. Developers are accustomed to Visual Studio UI and need to change their habits to work effectively with another debugger. Typical free debugger GUIs for Linux have limited capabilities and don't utilise the full power of GDB. Not always using such front-end is possible. The problem might occur on a machine where it's not installed and not always can be (e.g. if the machine is in the customer's office). All these situations make the process of fixing Linux platform specific bugs much longer and costly than it ought to be. In general, it can happen for each platform other than the standard development platform in a company.

WinGDB is designed to solve this particular problem for Visual Studio / GDB pair. It reduces development costs by giving the developers a possibility to work with debugging environment they know the best. Also the target machine configuration costs are minimized: all that is required is fairly recent version of GDB (6.8 or newer is perfect) and working SSH/SCP/SFTP server. Usually sshd is already in place and appropriate ports are accessible. If you can log in somewhere using putty, it's almost sure that you will be able to connect via WinGDB without additional configuration.

When we say "Linux", we think "Linux, or FreeBSD, or OpenSolaris, or OSX, or ...". In general, every platform that GDB and SSH work on, should also work with WinGDB. However, currently available version of WinGDB is being tested only with several popular Linux distros (x86/x86-64), Solaris / OpenSolaris (SPARC/x86/x86-64) and Palm webOS.

During debugging session use standard command 'Save Dump As' from Visual Studio menu 'Debug'.

Add to watch window name of register preceded with $, e.g. if there is register 'eax' add to watch '$eax'. After that you can change value of register just like value of any other item in watch (press F2/Tab or double-click on value). All changes will be automatically visible in Registers window.

In 'Launch Process' properties dialog there (left panel) is section 'Directories'. You can find there (right panel) property 'Additional Source Directories'. Insert directories according to description of that property.
If you use project you can set additional directories via project context-menu option "WinGDB | Properties".

Please go to Visual Studio Preferences ( Tools | Options | Environment ). Then choose section "Keyboard". Filter WinGDB commands with prefix "WinGDB.AddIn" and set preferred shortcuts.

Please let us know about it. Maybe we will be able to add some features or support which will work for your case.

At the moment it would be too expensive for us. We don't hire any special support/marketing staff yet. It's possible it will change in the future. Now you should consider WinGDB as a shareware product. Our primary support channel is e-mail (wingdb@wingdb.com). Please feel free to contact us in any case if you have any question, a problem with WinGDB, found a bug, or have a new feature idea.