Personal tools

Mobile/Fennec/Android/GDB

From MozillaWiki

Jump to: navigation, search

JimDB is a fork of GDB used for simplifying Fennec development. It consists of two parts:

Use #mobile on IRC for support.

Contents

Getting started

Using pre-built binaries

Instructions

  1. Download the latest pre-built binaries for your platform from this directory (use 'jimdb-arm' for ARM devices and 'jimdb-x86' for x86 devices)
  2. Extract to a user-writable directory
  3. Run 'git pull' from inside the utils/ directory to get the latest scripts
  4. Launch bin/gdb to start using JimDB!
  5. OPTIONAL: For easier access, you can create a symlink to jimdb under, e.g., /usr/bin

Example

For ARM devices on Linux,

cd $HOME
wget http://people.mozilla.org/~nchen/jimdb/jimdb-arm-linux_x64.tar.bz2 # step 1
tar -xf jimdb-arm-linux_x64.tar.bz2 # step 2
cd jimdb/utils # step 3
git pull
../bin/gdb # step 4
sudo ln -s $HOME/jimdb/bin/gdb /usr/bin/jimdb # step 5

Custom-building

Step 1. Compiling the binaries

There are two things to build here: gdb and gdbserver

Linux

GDB
  1. Clone the GitHub repo (do not use the Zip archive, as the build system will try to obtain a git changeset id)
  2. You may need to install additional packages in order to build GDB. For example,
    sudo apt-get build-dep gdb
  3. Run configure inside the source directory
    # ARM:
    ./configure --target=arm-linux-android --with-python=yes --prefix=/nonexistent \
      --with-gdb-datadir=/nonexistent/utils --with-system-gdbinit=/nonexistent/utils/gdbinit
    # x86:
    ./configure --target=i686-pc-linux-android --with-python=yes --prefix=/nonexistent \
      --with-gdb-datadir=/nonexistent/utils --with-system-gdbinit=/nonexistent/utils/gdbinit
  4. Run make
    make -j8
  5. The compiled binary will be at gdb/gdb
GDBServer

Consider using the pre-built gdbserver binary from the "Using pre-built binaries" section above; gdbserver is not specific to your platform. Otherwise,

  1. Use the source directory from above
  2. Make sure you have a copy of the Android NDK
  3. Run configure inside the gdb/gdbserver directory (following is for NDK r8d)
    export NDK=/PATH/TO/NDK
    # ARM:
    export PATH=$PATH:$NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin
    ./configure --host=arm-linux-androideabi --with-sysroot=$NDK/platforms/android-9/arch-arm
    # x86:
    export PATH=$PATH:$NDK/toolchains/x86-4.6/prebuilt/linux-x86/bin
    ./configure --host=i686-linux-android --with-sysroot=$NDK/platforms/android-9/arch-x86
  4. Run make
    make -j8
  5. The compiled binary will be at gdbserver

Mac

GDB
  1. Get a zip of the source from the GitHub repo (Get the zip because cloning takes a lot longer)
  2. Extract the zip
  3. You may need to install additional packages in order to build GDB. For example,
    port install bison flex ncurses texinfo python27
  4. Run configure inside the source directory
    # ARM:
    ./configure --target=arm-linux-android --with-python=yes --prefix=/nonexistent \
      --with-gdb-datadir=/nonexistent/utils --with-system-gdbinit=/nonexistent/utils/gdbinit
    # x86:
    ./configure --target=i686-pc-linux-android --with-python=yes --prefix=/nonexistent \
      --with-gdb-datadir=/nonexistent/utils --with-system-gdbinit=/nonexistent/utils/gdbinit
  5. Run make
    make -j8
  6. The compiled binary will be at gdb/gdb
GDBServer

Consider using the pre-built gdbserver binary from the "Using pre-built binaries" section above; gdbserver is not specific to your platform. Otherwise,

  1. Use the source directory from above
  2. Make sure you have a copy of the Android NDK
  3. Run configure inside the gdb/gdbserver directory (following is for NDK r8d)
    export NDK=/PATH/TO/NDK
    # ARM:
    export PATH=$PATH:$NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86/bin
    ./configure --host=arm-linux-androideabi --with-sysroot=$NDK/platforms/android-9/arch-arm
    # x86:
    export PATH=$PATH:$NDK/toolchains/x86-4.6/prebuilt/darwin-x86/bin
    ./configure --host=i686-linux-android --with-sysroot=$NDK/platforms/android-9/arch-x86
  4. Run make
    make -j8
  5. The compiled binary will be at gdb/gdbserver/gdbserver

Step 2. Creating JimDB directory

To get the most out of JimDB, in addition to the binaries, you need the Python scripts. But first, the scripts assume you have the following JimDB directory structure,

./bin/
    gdb
    gdbserver
./utils/
    gdbinit
    python/

Therefore, you'd need to,

  1. Make a JimDB directory
  2. Copy gdb and gdbserver from steps above to bin/
  3. Clone the Python scripts to utils/
  4. Run bin/gdb

For example,

mkdir -p jimdb/bin # step 1
cp /PATH/TO/SOURCE/gdb/gdb jimdb/bin # step 2
cp /PATH/TO/SOURCE/gdb/gdbserver/gdbserver jimdb/bin
git clone git://github.com/darchons/android-gdbutils.git jimdb/utils # step 3
jimdb/bin/gdb # step 4

Using JimDB

First run

In order to debug Fennec, JimDB needs a copy of your system libraries. When you try to debug Fennec on a particular device for the first time, JimDB will download the libraries from your device. This may take some time but will only need to run once. You may need to restart JimDB in order for debug symbols to work.

Configuring JimDB

utils/gdbinit is the GDB command file that JimDB runs at launch. Open it in your favorite text editor to see configurable settings for JimDB.

utils/gdbinit also loads utils/gdbinit.local. Because utils/gdbinit can change frequently across updates, it's recommended to copy your custom settings to utils/gdbinit.local, so that updates do not override your settings.

For example, to configure the feninit.default.objdir option, paste the following line anywhere inside utils/gdbinit.local,

python feninit.default.objdir = '/home/user/mozilla/central/objdir-android'

FenInit

FenInit is the Python script that simplifies launching Fennec on your device and setting up a debug environment. When JimDB starts, FenInit runs automatically and presents several options,

  1. Debug Fennec (default)
  2. Debug Fennec with env vars and args
  3. Debug using jdb
  4. Debug content Mochitest
  5. Debug compiled-code unit test

Jimdb-prompt.png

Debug Fennec

This is the default option. Once you choose an object directory to use, the script will automatically launch Fennec, and run GDBServer to attach to Fennec.

The script tries to scan your user directory for object directories. For more control, see the Configuration section on how to specify default object directories or where to scan for object directories.

Debug Fennec with env vars and args

This option gives you the additional ability to specify environment variables and arguments when launching Fennec. See the Configuration section on how to specify additional default environment variables and arguments.

Debug using jdb

This option will let you use the Java debugger (jdb) to debug the native Java portion of Fennec. This is the default option if you already have a previous JimDB debugging session running.

JDB support is experimental. It is able to at least set breakpoints, show source code, and examine objects.

Debug content Mochitest

This option will let you debug a regular Mochitest. Make sure Fennec is compiled with the '--enable-tests' option in the mozconfig file. Because running Mochitests require a copy of the XUL Runtime Environment (XRE), the script will offer to automatically download a copy of XRE for you, as well as launching the test harness. You can specify a file or a directory to test, or set TEST_PATH. Environment variables and arguments to the test harness are also supported.

Debug compiled-code unit test

This option will let you debug a C++ test. Environment variables and arguments are supported.

Configuration

feninit.default.objdir

  • Set feninit.default.objdir to the default object directory. Note that once it is set, the script will not prompt you to choose an object directory.
  • Alternatively, if your object directories are called 'obj*' under your source directory, you can set feninit.default.objdir to the source directory itself. The script will scan the source directory and list all the object directories that it found.
  • Note that there have been problems in the past with using ~ and $HOME in the setting, so use absolute path for best results.
  • PRO-TIP: Put the following code block inside gdbinit.local to always use the current directory as the object directory,
python
import os
feninit.default.objdir = os.getcwd()
end

feninit.default.srcroot

  • Unlike the previous setting, feninit.default.srcroot specifies the directory containing all the source directories. This is convenient if you have 'src/mozilla-central', 'src/mozilla-inbound', 'src/mozilla-aurora', etc. In that case, you can set feninit.default.srcroot to 'src' and all the source directories will be scanned for object directories.
  • Again, use absolute path for best results.

feninit.default.no_launch

  • This settings is meant for B2G, and may not be useful for Fennec debugging.

feninit.default.gdbserver_port

  • To debug Fennec on your device, GDB on your computer needs to talk to GDBServer on your device through a TCP port forwarded to your device through ADB.
  • Normally, JimDB will use a random port. However, you can pick a specific port to use. This is useful in certain situations such as inside an SSH session. See this blog post.

feninit.default.jdwp_port

  • Similar to feninit.default.gdbserver_port, except for using JDB for debugging.

feninit.default.env

  • Specify the default environment variables to use when launching Fennec. Only used for the "Debug Fennec" options.

feninit.default.args

  • Specify the default arguments to use when launching Fennec. Only used for the "Debug Fennec" options.

feninit.default.cpp_env

  • Similar to feninit.default.env, except only used for the "Debug compiled-code unit test" option.

feninit.default.mochi_env

feninit.default.mochi_args

  • Specify the default arguments to use when debugging Mochitest. Only used for the "Debug content Mochitest" option.
  • Note that Mochitest arguments are arguments to the test harness (e.g. --remote-webserver), and not arguments to Fennec itself.

feninit.default.mochi_xre

  • Specify the XRE directory to use, instead of letting the script download and manage an XRE copy.

feninit.default.mochi_harness

  • Specify the directory containing the harness itself, i.e. "runtestsremote.py". Not needed normally.

feninit.default.mochi_xre_url

  • Specify the directory on ftp.mozilla.org to use for downloading XRE. Not used if feninit.default.mochi_xre is specified.

feninit.default.mochi_xre_update

  • Specify the XRE check for updates interval. Only used if the script is managing the XRE copy, and not used if feninit.default.mochi_xre_update is specified.

GDB commands specific to JimDB

set delay-add-remote-solibs

gdb> set delay-add-remote-solibs <0|1>

Default setting is 0. Set delay-add-remote-solibs to 1 to delay loading symbols when shared libraries are loaded. This may improve the set up time. However, you may need to use the "sharedlibrary" command to manually load symbols before using breakpoints.

monitor set ignore-ondemand

gdb> monitor set ignore-ondemand <0|1>

Default setting is 1. Set ignore-ondemand to 0 to not ignore segmentation faults generated by on-demand decompression. This setting may be needed to debug specific segmentation faults that are inadvertently being ignored. This command can only be run after attaching to the target, so it cannot be specified in gdbinit.local.

FAQ

What is moz-gdb?

  • moz-gdb was a synonym for JimDB, but it's no longer used, to avoid confusion

"configure: error: failure running python-config" when compiling GDB

  • python may point to python3 on your machine. You need to specify where python2 is by using, for example, --with-python=python2 in your configure line

"error while loading shared libraries: libtinfo.so.5" on Linux

  • You may need to create a libtinfo.so.5 symlink to libncurses.so.5. For example,
sudo ln -s libncurses.so.5 /usr/lib/libtinfo.so.5

"Segmentation fault: 11" or "Illegal instruction: 4" on Mac OS X

  • This may be due to incompatible OS X SDK versions. You should build your own JimDB binary to avoid the issue.

"cannot locate symbol "__exidx_end"" when starting to debug

  • If you're using pre-built binaries, you need to update to a newer version of JimDB
  • If you're using custom-built binaries, you need to recompile gdbserver using a newer version of the NDK

"No module named printing" when debugging Fennec with JimDB

  • The JimDB Python scripts lack several scripts included in regular GDB packages. To fix that, simply copy your local copy of these scripts to the JimDB utils/python directory. For example, on a typical Linux system, run
cp -r /usr/share/gdb/python/gdb $jimdb/utils/python/
  • If you don't have these files, they are available here; just extract it under $jimdb/utils/python/

Random segmentation faults when debugging Fennec

  • GDB can catch segmentation faults generated by on-demand decompression; just use "continue" to continue execution.
  • Alternatively, specify the "MOZ_LINKER_ONDEMAND=0" environment variable when launching Fennec using Option 2. You can also put the option inside jimdb/utils/gdbinit.local.

GDB crashed and Fennec is stuck. Halp!!

  • GDBServer may still be attached to Fennec but is unable to communicate with GDB; try killing GDBServer
adb shell run-as org.mozilla.fennec_$USER kill `adb shell ps | grep gdb | awk '{print $2}'`

"make: `[path]/mochitest-remote' is up to date." while trying to run Mochitests

  • Delete the mochitest-remote file.

"failed to run gdbserver"

   "gdbserver" output:
    /system/bin/sh: /data/local/tmp/gdbserver: not executable: magic 7F45
   "run-as" output:
    /data/local/tmp/gdbserver[1]: syntax error: '(' unexpected
   "su -c" output:
    /system/bin/sh: su: not found
   [path]/jimdb-x86/bin/../utils/gdbinit:136: Error in sourced command file:
   failed to run gdbserver

You are probably trying to run the x86 version on an ARM device. Download the ARM version of JimDB instead.

JimDB sucks! Halp!!

  • Come on #mobile on IRC
  • Or file a bug under Firefox for Android, JimDB component

JimDB is awesome now!! Can I buy you a $beverage?

Yes! See also bug 800000