Android Emulator in C code debug--gdb/gdbservers when encountering a pit

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Write a HelloWorld first, create a folder in the Android source tree External/helloworld, add files:

// helloworld.c#include <stdio.h><stdlib.h>int main (intChar * * arv) {    printf ("Hello world~\n")     ; return 0 ;}

# Android.mklocal_path:= $ (call my-dir) include $ (clear_vars) local_module_tags:=  Optionallocal_module:=+ =-march=armv4local_src_files:= $ (call all-subdir-c-FILES) Include $ (build_executable)

Perform

$ mmm External/helloworld

Build the executable file.

• Launch the emulator and upload the file to be debugged to the emulator/data directory (note that you want to pass debug information)

$ emulator&$ adb pushout/target/product/generic/obj/executables/helloworld_intermediates/linked/ Helloworld/data

• Upload the Gdbserver to the simulator

$ adb Push Prebuilts/misc/android-arm/gdbserver/data

My platform is Mac OSX, the location of gdbserver under different platforms may be different. However, I found that there are gdbserver under the system/bin of emulator, so it should be possible to use this default if not transmitted.

• Start the native program via Gdbserver on the device

$ adb shell gdbserver:1234 /data/helloworld

• Forward the local TCP port to the TCP port of the device on the remote debugging machine

$ adb forward TCP:1234 tcp:1234

• Running GDB on a remote debugging machine

$./prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-gdb out/ Target/product/generic/obj/executables/helloworld_intermediates/linked/helloworld

GDB's path varies by platform, HelloWorld to ensure that the same executable program is being debugged on the emulator.

• Next is GDB's specific debug commands

(GDB) target remote:1234 # Gdbserverremote debugging using: Connected to emulator1234warning:unable toFindDynamic linker Breakpointfunction. GDB be is unable to debug shared library Initializersand track explicitly loaded dynamic code. Cannot access memory at address0x00xb3446658 inch??()(gdb) b mainBreakpoint1At0xb34665cc:fileEXTERNAL/HELLOWORLD/HELLOWORLD.C, line6. (GDB) C Continuing.warning:Could not load shared library symbols for 5libraries, e.g/system/bin/.linker. Use the"Info sharedlibrary"command to see the complete listing. Do you need"Set Solib-search-path"Or"Set Sysroot"?Breakpoint1, Main (argc=1, arv=0XBE8C5BA4) at EXTERNAL/HELLOWORLD/HELLOWORLD.C:66printf"Hello world~\n"); (GDB) n 5    { (GDB)  info  sharedlibraryfrom to Syms Read Shared Object Library No 
    /system/bin/linker No/system/lib/libc++. So No/system/lib/libc.so No/system/lib/libm.so No/system/lib/libnetd_client.so(gdb) set Solib -absolute-prefix out/target/product/generic/symbols/Reading symbols from out/target/product/generic/symbols/system/bin/linker ... Done. Loaded symbols forout/target/product/generic/symbols/system/bin/linkerreading symbols from out/target/product/generic/symbols/system/lib/libc++.so ... Done. Loaded symbols forOut/target/product/generic/symbols/system/lib/libc++. soreading symbols from out/target/product/generic/symbols/system/lib/libc.so ... Done. Loaded symbols forout/target/product/generic/symbols/system/lib/libc.soreading symbols from out/target/product/generic/symbols/system/lib/libm.so ... Done. Loaded symbols forout/target/product/generic/symbols/system/lib/libm.soreading symbols from out/target/product/generic/symbols/system/lib/libnetd_client.so ... Done. Loaded symbols forout/target/product/generic/symbols/system/lib/libnetd_client.so(gdb) Info sharedlibraryfrom to Syms Read Shared Object Library0xb3445e20  0xb345af18Yes out/target/product/generic/symbols/system/bin/linker0xb33bc920  0xb34032d8Yes out/target/product/generic/symbols/system/lib/libc++. so0xb331c8d0  0XB33685ACYes out/target/product/generic/symbols/system/lib/libc.so0xb32e8e30  0xb3300450Yes out/target/product/generic/symbols/system/lib/libm.so0xb32bcb08  0xb32be914Yes out/target/product/generic/symbols/system/lib/libnetd_client.so(GDB) ...

This part of the command is pure debugging, but I met the big hole here! The above sequence is connected to emulator, set breakpoints, continue, set dynamic Library search path, start debugging ...

Tell me about the pits and the phenomena I encountered. I think connecting the device, setting the search path are all built and configured for the environment, so they are all placed in front of the implementation. Next took two steps to receive the signal, saying it was an illegal command:

(GDB) target remote:1234 Remote debugging using:1234warning:unable toFindDynamic linker Breakpointfunction. GDB be is unable to debug shared library Initializersand track explicitly loaded dynamic code. Cannot access memory at address0x00xb1df5658 inch??()(GDB) set Solib -absolute-prefix out/target/product/generic/symbols/Reading symbols from out/target/product/generic/symbols/system/bin/linker ... Done. Loaded symbols forout/target/product/generic/symbols/system/bin/linker(GDB) n  -bl __linker_init(GDB) nprogram received signal Sigill, illegal instruction.notify_gdb_of_load (Info=0xbed759d8) at Bionic/linker/linker.CPP:194194rtld_db_dlactivity (); (GDB) L 189rtld_db_dlactivity (); the191Insert_soinfo_into_debug_map (Info);192193_r_debug.r_state =r_debug::rt_consistent;194rtld_db_dlactivity ();195    }196197static void Notify_gdb_of_unload (soinfo*Info) {198      if(Info-is_main_executable ()) {(gdb) 

At this point you have not touched the HelloWorld, the list to view the current location in bionic/linker/linker.cpp:194.

Google has a lot of children, some say this is a bug Android4.1.2, this kind of article is mostly in the 2012, and claims to have been fix off (http://code.google.com/p/android/issues/detail?id=40941). There is a suggestion that the line is now broken, and then modify the PC Register (http://visualgdb.com/android/linker-sigill/) I see the position of signal is by the arm instruction jump to thumb instruction, I tried, After the change, there are other problems. I am using the official Android 6.0.1_r11 version of the code number, should not have such a serious problem.

Later consulted other colleagues, found that his operation will be able to complete the debugging. The most obvious difference with my operation is that he will change a map port every time, and suspect that the used port mapping will cause problems. Then I go back and forth through his debugging process and find out that the real reason is the execution of the GDB command-don't set the so path too early.

Android Emulator in C code debug--gdb/gdbservers when encountering a pit