Android kernel debugging

Question

I experimented with getting kgdb for Nexus One to work.

I pulled the kernel from https://android.googlesource.com and turned on everything related to kgdb , including testing kgdbts using menuconfig , successfully built the kernel and displayed it on the device (which is unlocked and running CyanogenMod 7)

I also followed the instructions found at http://bootloader.wikidot.com/android:kgdb to enable the usb connection as a serial connection, as required by kgdb (and verified the connection from ttyACM0 to ttyGS0 successfully).

The following folders indicate that kgdboc and kgdbts were built into the kernel:

 /sys/modules/kgdboc/parameters /sys/modules/kgdbts/parameters 

Below is the dmesg result, showing that kgdbts testing kgdbts running, showing that (I think) is the successful completion of the tests:

 # dmesg | grep kgdb <6>[ 12.974060] kgdb: Registered I/O driver kgdbts. <6>[ 12.981781] kgdbts:RUN plant and detach test <6>[ 12.995178] kgdbts:RUN sw breakpoint test <6>[ 13.002441] kgdbts:RUN bad memory access test <6>[ 13.010864] kgdbts:RUN singlestep test 1000 iterations <6>[ 13.019042] kgdbts:RUN singlestep [0/1000] <6>[ 13.077850] kgdbts:RUN singlestep [100/1000] <6>[ 13.132720] kgdbts:RUN singlestep [200/1000] <6>[ 13.187500] kgdbts:RUN singlestep [300/1000] <6>[ 13.242370] kgdbts:RUN singlestep [400/1000] <6>[ 13.297149] kgdbts:RUN singlestep [500/1000] <6>[ 13.351928] kgdbts:RUN singlestep [600/1000] <6>[ 13.406829] kgdbts:RUN singlestep [700/1000] <6>[ 13.461578] kgdbts:RUN singlestep [800/1000] <6>[ 13.516540] kgdbts:RUN singlestep [900/1000] <6>[ 13.570922] kgdbts:RUN do_fork for 100 breakpoints <6>[ 21.117645] kgdb: Unregistered I/O driver kgdbts, debugger disabled. 

I believe the problem I am facing is getting the kernel to start kgdb .

 # echo -ng > /proc/sysrq-trigger 

It just drops me back to the command line and (I think) that this should freeze everything and send a request to usb, which is used as the psuedo serial port, since the phone has no real one.

From what I collect from my research, the invitation should be a trigger that will allow me to release

 (gdb) target remote /dev/ttyACM0 

And connect to the kernel debugging session.

I also tested /proc/sysrq-trigger with b and c only to confirm that I can pass some sysrq commands.

So, my question, following my lengthy attempt to provide as much information as possible, is the reason that g does not start the debugger?

This is my first attempt at debugging the kernel on any system, and I did not have the opportunity to talk about my google search, so I am contacting you. Thank!

(I also tried putting kdgbwait on the kernel command line without success, as I believe this is not yet supported by the android kernel)

Answer 1

Android kernel questions are rarely found on [SO] since no one else answered. I presented my findings on this issue. Unfortunately, I have no connection to check this, so this answer is not intended as a step-by-step solution to your problem, but should point you in the right direction where to look.

The only useful resource I found in this problem is the LKML patch from Dongdong Deng , so this is hardly a configuration problem, as they are usually plentiful and well -publicized.

This indicates that there is a problem with your kernel build. I would have a desire to start working with the latest versions of CM again and see if the problem disappeared.

Otherwise, try reporting this to the cyanogen command and see if this is a known issue or has an easy workaround.

As a last resort, you can try the patch if the versions are compatible. The only alternative is to roll up the sleeves and start cracking the CM core to enable the patch.

Good luck.

Answer 2

I have no experience with Android hardware, but I executed the compiled kgdb kernel, running as a VirtualBox client, and from the host I connected to the guest through a virtual serial port and using gdb (with the standard command "target remote") I can go through through the entire load of the virtual guest kernel - using kgdbwait. Without this, I can write a kernel module that does nothing but implement a built-in assembly called "int 13" that is 0xcc. After loading, a breakpoint will be displayed on the host side of the serial connection, and then I can set a breakpoint and continue removing the kernel. This works because kgdb handles the "int 13" exception. If u explicitly throws another exception like "* p = 0" and p points to NULL, u will still get a breakpoint, but I doubt that u can continue execution.

Answer 3

I found this post from a related post and wanted to say that I just posted some work that I did to get this to work on Nexus 6 if anyone is interested:

http://www.contextis.com/resources/blog/kgdb-android-debugging-kernel-boss/

Interestingly, the OP issue with sysrq was one of the ones I ran into. The reason for this behavior is that KGDB did not initialize correctly, so it could not install a handler for the "g" trigger (kgdb). This is why all the other sysrq commands still work.

Longer explanation (thanks @Robert):

To get this working, I had to make a UART debugging cable based on this Accuvant blog . This is a fairly simple circuit that consists of the FTDI 3.3v main breakthrough (available from SparkFun at the time of writing), as well as 4 resistors (2 x 1K Ohms, 1 x 1.2K Ohms and 1 x 100 Ohms) and a 4-element headphone jack Tip-Ring-Sleeve (TRRS). Resistors essentially provide a voltage divider to reduce 3.3V to something more secure for your phone. By inserting an audio jack with the other end connected to your circuit board, the audio subsystem recognizes that a voltage (~ 2.8 V) is on one of the pins, and it knows to provide a UART interface through this cable. The FTDI gap is connected to the computer via USB, and from here you can access console messages through a terminal emulator, such as a minicomputer. However, you now have a serial interface through the same mechanism and that we can use to connect KGDB.

So, at this point, relatively small changes are required for the Nexus 6 serial driver (msm_serial_hs_lite.c) to support KGDB (in particular, the ability to perform I / O using an atomic symbol). I just ported these changes from the main Linux kernel code, as a chapter called Stephen Boyd did a great job with the full serial driver MSM (Qualcomm) msm_serial.c. Its changes can be found here or just search "msm_serial: add poll_ support" on Google. The port was not complicated, and my code can be found on github .

In addition, you should be able to create your own kernel for your N6, which google provides a lot of information about . Then you need to create a boot image containing the KGDB modifications in the github repository. I took the original kernel from https://developers.google.com/android/nexus/images , extracted it (using abootimg -x), and then used the following command to repackage it using my custom kernel (zImage-dtb ) and additional command line parameters to ensure that KGDB is loaded and points to my serial port as follows:

 abootimg -u boot.img -k zImage-dtb -c 'cmdline=console=ttyHSL0,115200,n8 kgdboc=ttyHSL0,115200 kgdbretry=4' 

With boot.img created, I could boot into it using the fastboot boot boot.img command, open the adb shell, and then launch a breakpoint in the Android kernel with the command:

 echo -ng > /proc/sysrq-trigger 

It should be noted that for completeness, you need superuser privileges to access / proc / sysrq -trigger, so you need to have root.

With the phone stopped and the debugging cable connected, run the GDB version for ARM on your PC with an uncompressed kernel as an argument (for example, arm-eabi-gdb./vmlinux). Note. I am running Ubuntu 14.04 and using arm-eabi-gdb from the prebuilts directory in my original AOSP repository. Finally, enter the following commands:

 set remoteflow off set remotebaud 115200 target remote /dev/ttyUSB0 

Everything should be fine, it should immediately break into the kgdb breakpoint (so that your write is done in / proc / sysrq -trigger), and you can start debugging.