Native Android debugging has always been somewhat tricky. In addition to common source path issues and random gdbserver failures, many VisualGDB users reported that they can debug code on their device only if they use certain versions of NDK toolchains. To figure it out once and for all we have added a VisualGDB feature that allows testing a certain Android device with all the toolchains available in the NDK. To get a general overview we have tested the standard ARM emulator images that come with the Android SDK.
Continue reading About Android toolchains and system images →

We have released a new version of SmarTTY, our free multi-tabbed SSH client. The new release focuses on improving usability and making common scenarios simpler. Let’s overview the main features of the new release:
Continue reading SmarTTY 2.0 is out →

After several preview builds of VisualGDB 5.0 with the new Clang-based IntelliSense engine introducing features from precise code suggestions to fast find-all-references, we are now proud to release the first beta of VisualGDB 5.0. The beta adds a few more features targeted at C++ development productivity:

• CodeMap for C++ (requires VS2012+, but also works on the free Community Edition)
• Advanced renaming
• Intuitive refactoring

Let’s have a detailed look at those new features.
Continue reading VisualGDB 5.0 Beta 1 – Refactoring and C++ CodeMap →

We have recently released a new preview build of VisualGDB 5.0 featuring a new Clang-based IntelliSense engine. This preview build focuses on greatly improving the experience with navigating large code bases. In this post I will show how to quickly analyze the code structure and navigate in 2 large codebases:

• The source code of clang itself (~30MB of C++ sources)
• The source code of the Linux Kernel (~420MB of C sources)

Continue reading Exploring code with VisualGDB 5.0 Preview 4 →

One of the annoyances of C++ compared to higher-level languages like C# is the relatively large overhead when creating new methods or functions. Unlike C# where you can just call the not-yet-existing method and then select “create method stub”, C++ makes things harder: creating a new method normally means manual edits to both header and source files, that can quickly get annoying.

To help VisualGDB users improve their productivity the newest VisualGDB 5.0 Preview 2 build contains a special create-from-use engine that automates method creation in a smart way.
Continue reading The new Create-from-use engine makes C++ coding easier →

OpenOCD is a great tool. It allows debugging many modern ARM-based microcontrollers using multitudes of JTAG/SWD programmers: from the $50 FlySwatter to the $800 J-Link Pro. It allows customizing lots of settings and it’s open-source so if you encounter some problems with it, you can quickly pinpoint them by stepping through its code. Despite all those strong sides, it has one major drawback – it’s not easy to setup.

A typical OpenOCD debugging setup involves finding the correct initialization scripts, customizing them to match your device/interface and often manually preparing and installing USB drivers. Although generally doable, this looks like a major inconvenience for anyone who expects a “plug-and-play” experience.
Continue reading OpenOCD usability taken to a new level →

If you are using a cross-compiler to build a non-trivial Linux app (e.g. including QT libraries), you may encounter errors like this when linking your binary:

ld.exe: warning: libfontconfig.so.1, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link)
ld.exe: warning: libaudio.so.2, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link)
ld.exe: warning: libglib-2.0.so.0, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link)
ld.exe: warning: libpng12.so.0, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link)
ld.exe: warning: libz.so.1, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link)

The output is usually followed by a long list of undefined reference to `xxx’ errors.
Continue reading Fixing -rpath-link issues with cross-compilers →

Using cross-compilation toolchains to build code for your embedded Linux boards (such as Raspberry PI) can be cool. It’s faster than building your code on a slow embedded box with few RAM and disk space, it’s easier to edit files directly, it’s more comfortable to have all necessary files at hand.

There’s one common problem, however. If you use your cross-compilation toolchain to debug a remote Linux box using GDBServer, you may end up in a situation when GDB silently fails to load symbols for your libraries unless you manually execute the sharedlibrary command. This article explains why this happens and how to resolve it.
Continue reading Resolving library symbol load errors when debugging with cross-toolchains →

If you have ever tried debugging anything (especially the native code) using the Android AVD Manager, you have probably noticed how slow it is. Taking minutes to load symbols, multiple seconds to do a single step, sometimes eternity to load and start a massive app…

The reason for it is how the emulation is implemented. Trying to emulate an Android device with an ARM CPU is not an easy job for your desktop computer or a laptop with an x86/x64 processor. The ARM instructions are completely different from the x86 ones so your host CPU cannot execute them directly. Although the Android emulator seems to be based on QEMU that supports dynamic translation, the results are still far from being impressive – a real Android device is usually around 10 times faster.

Things go differently when you want to emulate an x86-based Android device. As the instruction set is now compatible with the one used by your computer’s CPU, the emulation can be done using hardware virtualization techniques and can get as fast as VirtualBox or VMWare do when virtualizing another desktop OS.

A small tool that makes such blazing fast virtualization possible is the Intel Hardware Execution Manager a.k.a. HAXM – it installs as a background service and automatically comes into play when you start an x86-based virtual Android device:

You can easily use it to test your projects with the Android x86 emulator, but you’ll need to do a bit of additional setup selecting x86 as the app ABI if your project uses native code. We’ve published a detailed tutorial explaining how to setup HAXM A to Z.

Enjoy your debugging!

Native Android development can be really puzzling. Multiple tools, multiple versions, undocumented features, script errors, Google clearly stating that NDK will not benefit most apps…

As of February 2013, there are two ways of building a native Android app with Visual Studio: our VIsualGDB tool and the vs-android project. Although vs-android does not include a debugger, it is still used by many developers to build native Android apps. The key is its build system. Being based on the new MSBuild engine introduced with Visual Studio 2010, it creates a separate platform in Visual Studio using the Android GCC instead of Microsoft C++ compiler. Although this does not involve NDK makefiles and will not automatically reflect any changes made with the new NDK releases, it is still a pretty smooth way of building your Android app.

Having said this, we’re proud to announce that VisualGDB 3.0 is now compatible with vs-android. We have made it really simple and smooth: simply open an existing vs-android project, select it as the startup one and then use the Android->Debug Android App command in Visual Studio to deploy and debug it automatically.

There is also a detailed step-by-step tutorial on debugging vs-android projects with VisualGDB.