从AMD主机调试在Intel目标上运行的linux内核-如何将控制权返还给gdb？

Question

I have compiled kernel 3.13.0-55 on Ubuntu on both AMD and Intel machines. I tried to copy compiled kernel to Intel target but it won't boot with that one. Therefore I have compiled the same version of kernel on that Intel. I can run this kernel on Intel and Intel waits for kgdb to attach to it. I do it on AMD with

target remote /dev/ttyS0

and I am able to step into kernel code over serial connection. I do continue then, and if I set some breakpoints, for example at vfs_read then yes - it is hit. But when I write g to /proc/sysrq-trigger on the target Intel, after I typed continue in gdb on host and Intel continued to run, then the target halts, and I cannot return the control to debugger running on AMD any more. Writing g to /proc/sysrq-trigger halts the Intel but control isn't returned to the AMD gdb.

I suspected this might be caused due to it is not EXACTLY same (not copied) version of kernel, but copied version of kernel from target machine doesn't change this behavior either. How should I troubleshoot this problem? How to return the control to debugger? What can I test/verify/check? What additional info do you need? Please let me know. Enable Magic SysRq is set in kernel config.

uname -a:

AMD:  3.13.11-ckt20 #5 SMP Tue Jun 30 17:52:33 BST 2015 x86_64 x86_64 x86_64 GNU/Linux

Intel: 3.13.11-ckt20 #2 SMP Tue Jun 30 17:10:47 BST 2015 x86_64 x86_64 x86_64 GNU/Linux

GDB sesion:

peter@peterubuntu0:~/kernel$ sudo gdb vmlinux_intel 
Reading symbols from vmlinux_intel...done.
(gdb) set serial baud 115200
(gdb) set debug remote 1
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+#b5...Ack
Packet received: 
Packet qSupported (supported-packets) is NOT supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received: 
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC01
Sending packet: $qAttached#8f...Ack
Packet received: 
Packet qAttached (query-attached) is NOT supported
Sending packet: $qOffsets#4b...Ack
Packet received: 
Sending packet: $g#67...Ack
Packet received: 2f000000000000000000000000000000a80b0000000000006c1c0000000000006c1c000000000000460200000000000038de8b260388ffff38de8b260388ffff960000000000000022020000000000000100000000000000aaaaaa00000000002084ca81ffffffffe30000000000000000000000000000000000000000000000f4201081ffffffff0202000010000000000000000000000000000000
kgdb_breakpoint () at kernel/debug/debug_core.c:1042
1042        wmb(); /* Sync point after breakpoint */
Sending packet: $qSymbol::#5b...Ack
Packet received: 
Packet qSymbol (symbol-lookup) is NOT supported
(gdb) c
Continuing.
Sending packet: $vCont?#49...Ack
Packet received: 
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack




^Casync_remote_interrupt called            // this is where I did Ctrl+C
remote_stop called
^Casync_remote_interrupt_twice called      // and Ctrl-C again
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
Quit

---

EDIT:

Though it doesn't work when I try to debug Intel from Amd (both running the same kernel 3.13.11-ckt20 SMP 2015 x86_64 x86_64 x86_64 GNU/Linux ): target - Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz host - AMD FX(tm)-4100 Quad-Core Processor

it works in the opposite direction: target - AMD FX(tm)-4100 Quad-Core Processor host - Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz

Maybe it is related to hardware breakpoints, registers, cpu implementation?

Answer 1

When you set breakpoints and write continue , you can do a ctrl + c on gdb to write a new command , for example : info registers to see registers status from the start to your breakpoints .

Or Try out this using Qemu and gdb . you can use

Qemu -s -S , qemu will listen on localhost:1234

then in gdb use target remote localhost:1234

If you invoke qemu from within gdb, you'll probably want to skip SIGUSR1 ("handle SIGUSR1 noprint").

You can also invoke qemu with the -gdb option (or -s shortcut) which provides a gdb stub. You can then connect from any machine on the network (start up gdb, then use "target remote :"). See the man page for more information.

Depending on what you are trying to debug, it may help to use the -S option to qemu (which freezes the CPU on startup), so you can get qemu up, attach gdb and get it set up, then continue.

On some architectures, using hardware breakpoints (gdb hbreak command) may work better than software breakpoints (gdb break command)