How to Compile Android’s GDB Debugger Client

At windows command prompt, execute this command, assuming NDK already installed at C:\NDK and gdb already created as a folder below D:\Projects\Android\toolchain


Then I arrived at this absurd message:


I can’t believe my own eyes, that one of biggest corporation on earth, created such an ridiculous script like above. A direct violation of principle of equality. This is because I can compile well my gdbserver previously on windows OS machine for codes FOR Android ARM platform, but I can’t compile gdb client FOR windows platform for ARM architecture. Clearly a shameful act, and if not changed, will lead to eventual downfall.

So, enough of the rambling, let’s perform some action to rectify this situation πŸ™‚

Using the marker such as ‘xxx’ string, etc, I eventually found that the message is orginated from script statement inside


So, inside _bh_select_toolchain_for_host function, there’s a condition checks, and because I try to create windows executable using –systems=windows parameter, it checks for $BH_BUILD_OS, and if it is linux, the above script is executed, but because my OS is windows it goes to:


Let’s see what happens when I try to add the new condition for windows also:


Now I got this message:


I prefer to use my MINGW compiler, because it is already proven to successfully compile the emulator-arm.exe on my windows machine, so let’s taught this script to use MINGW compiler instead of CYGWIN one. Inside my machine, I already have mingw32-gcc.exe (C:\MINGW\bin) that should hopefully provide successful compile.

To do this, I have to examine and modify the _bh_try_host_prefix function inside file. By examining the function, it is revealed that the function tries to find the relevant exe by concatenating the prefix with -gcc string. So, in order to make the script to find my mingw32-gcc.exe, I added this call in the condition check:


Here’s what I got after this modification:


This error message is originated from _bh_check_compiler_bitness ( function. Let’s create more information to the screen from this function:


Here’s the output:


The command is clearly malformed, maybe because of the script is assuming compile under linux environment, so it is required to create the customized script to handle windows situation. After backing up the, it is time to perform heavy revision to this script.


This is caused by non-existent expat source. So, after placement of expat source code into D:\Projects\Android\toolchain\expat, and changes the BUILD_DIR variable inside


We have:


Seems that configure managed to create the makefile and now it tries to compile the expat module, like the solution from previous post, let’s copy the required files from original directory to the one already created by configure program (i.e. from D:\Projects\Android\toolchain\expat\expat-2.0.1\lib to C:\NDK\tmp\buildgdb\build-expat-2.0.1-windows\lib).

And because I don’t one to start from the beginning, lets move to the C:\NDK\tmp\buildgdb\build-expat-2.0.1-windows and run the make program from there.


This is caused by malformed library name directory and causes bash shell adds the mysterious C:\MSYS\1.0\OUT directory and breaks the LIB.EXE provided from Microsoft. This is evident from the log file generated by procmon when the bash.exe tries to execute the program as follows:

Command line: “c:\Program Files (x86)\Microsoft Visual Studio\VC98\bin\lib.exe” C:\MSYS\1.0\OUT;.libs\libexpat.lib lib/xmlparse.o lib/xmltok.o lib/xmlrole.o, Current directory: C:\NDK\tmp\buildgdb\build-expat-2.0.1-windows\

This can be fixed by modifying the generated libtool shell script inside C:\NDK\tmp\buildgdb\build-expat-2.0.1-windows as follows:


The strings “.libs” causes bash.exe to break the execution of lib.exe so let’s change it to libs by omitting the “.” character and creates the appropriate libs folder there, and re-run the makefile:


It ask for more items, so let’s give what it want. After re-starting make program, now I have libexpat.lib, as the output. So, let’s get to the next stage. This is done by commenting the need_build_expat inside file and re-run the shell. This will result in folder structures inside C:\NDK\tmp\buildgdb as follows:


Each folders contains makefile generated by configure program and ready for some actions. From here, we can leave the configuring phase, and advanced through make phase. Let’s try to make programs inside build-gdb-windows-android-arm-6.6 folder:


Copy the required file from D:\Projects\Android\toolchain\gdb\gdb-6.6, we have:


The ar.exe is actually already exist, so let’s create another copy of ar.exe and rename it to mingw32-ar.exe:


Perform the same operation for ranlib.exe:


Copy file from D:\Projects\Android\toolchain\gdb\gdb-6.6\bfd\doc to C:\NDK\tmp\buildgdb\build-gdb-windows-android-arm-6.6\bfd\doc. And repeat this action for other “no rule” issue, we arrive at:


Error message is multiple target patterns. Stop. This is slightly different from previous one, well, by examining the line 264 in makefile file, we have:


Let’s check the POTFILES variable content:


Clearly another malformed file notation format, because there are extra “../” characters in front of file directory info. By removing those extra chars, now we have:


Seems the configure program decides nothing to be build inside this directory. Let’s proceed to the build-gdb-windows-android-arm-6.6 directory again and execute the make file process again:


Back to the usual error message, by giving what it wants finally arrive at:


And this causes bash shell to stop working, i.e. crashes πŸ™‚


But checking the presence of, the file apparently created, so re-run make and I arrive at different situation:


Perform extensive search, what I found is only *.LIB generated by compiler by earlier phase, so is it possible to perform link using this files ? By copying this *.LIB files to the respective directories and rename to *.a to avoid the hassle of modifying makefile file, the run.exe is now exist and appears to be normal.


After performing more boring process of copying and make re-run, we seems to close to create the coveted gdb.exe except for the show-stopper below:


Searching for presence of function observer_notify_executable_changed proves to be futile, because it is none to be found in existing gdb source. So, after some more detailed analysis, I came to the curious file called which seems the shell to generate the required function inside And by examining the, there’s only empty file with only notification comments on it, so let’s delete the file and force makefile to recreate the file:


So, this file should be created manually:


Same cases for observer.h:


Perform re-run of make and this time, the gdb.exe is now exist. Let’s call this newly born program:


Q.E.D. and so far so good πŸ™‚


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: