We have released VisualGDB 5.0 Beta 3! This release focuses mainly on usability features for embedded projects that have been requested by the community.
First of all we have added support for live variables – a convenient way to inspect the global variables in your program without stopping it. VisualGDB supports real-time plotting, data breakpoints and can export the data to CSV:
Continue reading VisualGDB 5.0 Beta 3 is out
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:
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:
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!