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

gdb01

Then I arrived at this absurd message:

gdb02

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 common-build-host-funcs.sh:

gdb03

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:

gdb04

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

gdb05

Now I got this message:

gdb06

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 common-build-host-funcs.sh 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:

gdb07

Here’s what I got after this modification:

gdb08

This error message is originated from _bh_check_compiler_bitness (common-build-host-funcs.sh) function. Let’s create more information to the screen from this function:

gdb09

Here’s the output:

gdb10

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 common-build-host-funcs.sh, it is time to perform heavy revision to this script.

gdb11

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 build-host-gdb.sh:

gdb12

We have:

gdb13

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.

gdb14

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:

gdb15

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:

gdb16

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

gdb17

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:

gdb18

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

gdb19

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

gdb20

Perform the same operation for ranlib.exe:

gdb21

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:

gdb22

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:

gdb23

Let’s check the POTFILES variable content:

gdb24

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:

gdb25

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:

gdb26

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

gdb27

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

gdb28

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

gdb29

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.

gdb30

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:

gdb31

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 observer.sh which seems the shell to generate the required function inside observer.inc. And by examining the observer.inc, there’s only empty file with only notification comments on it, so let’s delete the file and force makefile to recreate the file:

gdb32

So, this file should be created manually:

gdb33

Same cases for observer.h:

gdb34

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

gdb35

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

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: