A collection of problems I ran into using VisualGDB

[paul90]

Hello,

Before I begin, Allow me to express my appreciation to this great tool.

Notes:
1. My workstation is Windows 7 x64.
2. I develop native tools for android – Linux style, on a rooted device.
3. I mainly use galaxy s4, 4.4.2 to debug programs, and I compile my programs mainly to armeabi-v7a.
4. I’ve been able to use my own makefile based build system, and integrating it into the VisualGdb via visual studio NMake menus.

After using VisualGDB for a while, I can say that I ran into the following issues and scenarios:
1. Most of the [arm-Linux-androideabi-gdb.exe / gdbserver] combinations did not work out of the box and crashed a lot,
the only combination that has worked, was a gdbserver from android ndk r10 (ndk32 and windows_x64) which is version 7.6, and
the arm-linux-androideabi-gdb.exe 7.4.1 from the following link: http://gnutoolchains.com/android/.
I know that this is not ideal, since the versions mismatch, but neither the gdbserver from the link above and the ‘arm-Linux-androideabi-gdb.exe’ from ndk r10 worked.
Breakpoitns did not occur with the gdbserver from the link, and the arm-Linux-androideabi-gdb.exe from ndk r10 crashes every time.
2. As I’ve said, I use my own makefile to build my binaries, with a workaround that copies my binaries to the libs/ and obj/local directories that VisualGDB expects, and
placing a jni directory with an almost empty ‘INCLUDE_BUILD_EXECUTABLE’ Android.mk, that I don’t need.
I want to ask whether I can avoid that workaround.
3. During a debugging session, if I’m correct, VisualGDB identifies shared objects by their names, It would make it easy for me to have the names configurable,
for instance, if my main executable is named ‘example’ and my shared object that is loaded via ‘dlopen’ is named ‘libexample_android.so’ on the computer,
I want to let VisualGDB know that ‘libexample_android.so’ is actually ‘libexample.so’ on the android device so it can recognize its source code.
4. So far, another workaround I implemented, was running executables as root, by specifying a ‘gdbserver’ that is a shellscript that contains
#!/system/bin/sh
su -c /data/local/tmp/gdbserver_orig # the real gdbserver

I wonder if I can avoid that as well.
4. Another important problem I ran into, is that I want to attach to another processes, as root, that process is not an app process.
I tried the attach to process method, it displays a greyed out display.

thanks in advance.

[support]

Hi,

1. Unfortunately, the Android tools provided by Google are not very stable, so you often need to try several combinations to find one that works.
Note that if your breakpoints don’t work, this can be caused by 3 independent problems:
a. Gdbserver fails to get the shared library list from the OS. This can be detected by checking the output of ‘info shared’ for strange things. It can be fixed by trying various gdbserver versions.
b. Particular versions of gdb and gdbserver are incompatible. This would cause either of them to crash. A workaround would be to try different versions of gdb/gdbserver.
c. The debug symbols produced by gcc are not correctly recognized by gdb. This would cause the modules to appear properly, but the breakpoints won’t set or the variables will be missing. It can be fixed by changing the debug information format of gcc (-gdwarf-xxx flags) or using a different gcc version.

2. VisualGDB expects a certain file layout coming from NDK build scripts and the easiest way to support a custom build system is to emulate it just like you are doing it.
3. This is actually handled by gdb itself, not VisualGDB. When the target loads a library called xxx.so the GDB searches the directories set via set solib-search-path for a library with a matching name and gets symbols from there. The easiest workaround for mismatching names would be to simply make a copy of the file on the Windows side with a matching name. You can also put it into a different directory and specify it via set solib-search-path.
4. We also don’t have any special flag for starting gdbserver as root. We could add a flag for that, but if the current workaround works, we would suggest using it as it’s a fairly rare scenario.
5. The normal Attach dialog does not support attaching to Android processes. We will consider adding support for this in one of the next releases.

[Author]

Posts