When sending the step command from my host machine running gdb to my remote target (connected over TCP/IP) running the gdbserver, I receive the following error on the target
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
Nothing happens on the target after this - just hangs. On the host's gdb, the following is displayed
(gdb) step
warning: Remote failure reply: E01
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
This will continue indefinitely. Ends up with me having to reboot the target. continue works just fine and is able to trigger on my designated breakpoints. Could this fault be entirely on the gdbserver side or could it have something to do with my gdb configuration?
gdbserver version on the target
GNU gdbserver (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC
4.9-2014.09) 7.6.1-2013.10
gdb (built from source) version on the host
GNU gdb (GDB) 7.7.1
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Looks like the issue I was having was due to an incorrect target when compiling the host GDB. For the target processor I'm using, I needed to set the target flag to
--target=arm-linux-gnueabihf
So far, I'm able to step through my code as well as trigger on segfaults.
Related
I am trying to debug a cross-compiled application with gdbserver. Unfortunately I get the following error on my host:
Reply contains invalid hex digit 59
Here's what I did:
compiled my application "line-generator" (which is just a test program) with gcc -ggdb3 -std=gnu89 flags (using -g instead of -ggdb3 didn't make any difference)
copy the executable to my embedded system. The exec can be executed there
started gdbserver 192.168.10.20:54320 line-generator on the embedded system
On the host I start gdb: gdb line-generator.gdb
(gdb) target remote 192.168.10.102:54320
Got this response on host:
Remote debugging using 192.168.10.102:54320
Reply contains invalid hex digit 59
On the server I got this:
Remote debugging from host 192.168.10.20
readchar: Got EOF
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 54320
I have never used gdb remotely so maybe I am running into a beginner's issue so every response might help.
edit: My gdbserver was provided by the manufacturer of the embedded hardware.
I found out that remote-debugging a cross-compiled executable needs gdb on the host computer to be compiled for this purpuse. In my case it means that I have to use this command
/opt/microblaze-uclinux-tools/bin/microblaze-uclinux-gdb line-g
enerator.gdb
instead of simple gdb line-generator.gdb
Luckily the correct file was provided by the embedded board manufacturer!
To be honest I don't fully understand the context so if someone has an explanation on this I'd be glad to hear this!
cheers, Stefan
I have a Linux script written in C Language deployed at a remote server, to which multiple clients can connect. Due to some reason the script crashed and when I am trying to restart it I am getting segmentation fault.Is there any way by which I can Check at server side that what is stopping my script from starting, and is throwing segmentation fault error.
Start out by enabling core dumps:
$ ulimit -c unlimited
Now run the script until it segfaults. This will create a core dump file in your working directory.
Next, use GDB (or any frontend of it) to debug it (note that you can copy the file to your local machine if you can't debug on the server):
$ gdb -c <core_file>
Don't forget to add the symbol file:
GDB> file my-prog
If it's easy to reproduce the problem, and provided you can debug directly on the server (with SSH or such), you can simply dive in and start the process with a debugger attached:
$ gdb my-prog
I want to debug linux kernel, which is running on qemu using gdb.
i ran the kernel on qemu using below command.
qemu-system-i386 -kernel ../bzimage -initrd ... / *.image -nographic
--append "console =ttys0 init =/init" -s -S &
now i want to run gdb
gdb vmlinux
(kernel symbols are loaded)
gdb target remote:1234
now i am getting below error
remote:1234 connection timeout.
I saw the same problem. Somehow running qemu in the background (with the trailing '&') won't work. You just have to run gdb from another shell.
You got the host to connect to wrong.
It should be
target remote :1234
Note the space. Otherwise gdb parses the command as a host named remote.
Also, try running QEMU without the ampersand character.
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?
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)
I am working with openvswitch on ubuntu 14.04 server. I can easily attach gdb with any of its binary files for debugging its various features but when it comes to its kernel module, I am not able to debug it as per my requirement.
I am using following steps to attach linux kernel with gdb:
1. gdb /tmp/vmlinux /proc/kcore
2. Adding a symbol File to GDB:
cd /sys/module/openvswitch/sections/
ls -A1
.cat .text .data .bss
3. in gdb - add-symbol-file datapath/linux/openvswitch.ko 0xf87a2000 -s .data 0xf87b4000 -s .bss 0xf87b4560
4. b vxlan_udp_encap_recv
but when I generate packets for testing ovs kernel module and step over it says "The program is not being run."
Note: I have confirmed all module symbols by running this command: nm root/ovs/_build-gcc/datapath/linux/openvswitch.ko = which prints all symbols. and lsmod also confirms the existence of ovs kernel module.
I want to make ovs module stop at specified break point after it receives a message from its user-space application on netlink socket for its detailed debugging as conveniently as it allows me to debug a user-space process. Please suggest me how do I resolve this problem or if there is any alternative. I'll be really grateful for any help or suggestion. Thank you!
To debug the kernel you need to use KGDB / KDB.
one possibility:
run the gdb server on the target machine. run gdb on another machine. recompile the target machine kernel with the -ggdb parameter on gcc. start both machines with the target machine running the kernel with all the -ggdb info. have all the source available on both machines. connect from the testing machine to the target machine. have the gdb server connect to the kernel ....