I'm trying to debug a program on my board which runs an embedded linux and I have Ubuntu as host system. I have a big problem with gdbserver. You see the thing is that my board doesn't have an Ethernet interface but a serial device which I'm using for console and I noticed that you can use a serial device for debugging in gdbserver although I couldn't find an example of this considering everyone that used gdbserver in videos or books used it in TCP mode which I can't do that.
So What I did was simply running gdbserver on the board this way:
root#DM368# gdbserver /dev/ttyS0 hello
Process hello created; pid = 472
On the host side I'm using ddd program and I ran:
root#mosi-VirtualBox:~# ddd --debugger arm-linux-gdb
And in ddd window terminal I entered:
(gdb) cd /root/home/mySimpleHello/hello
(gdb) target remote /dev/ttyUSB0
(gdb) file hello
And /dev/ttyUSB0 is connected to the board's /dev/ttyS0
But I don't get anything back in gdb and there is nothing in gdbserver output which is kind of weird. I mean not a single message like a "host connected" or "remote debugging from ..." or things like that. And in ddd when I ran:
(gdb) b main
Breakpoint 1 at 0x83ac: file hello.c, line 10.
(gdb) run
Then gdb says:
the program in not being run
I tried with gdb on Ubuntu's terminal directly (whitout ddd) and the same thing happened. I even tried with eclipse and I setup a debugging profile in eclipse and I installed gdb-multiarch program and used that in eclipse with its .gdbinit file set to arm. Nothing happens and I have no idea why this simple procedure wouldn't work.
Does somebody have any idea? What am I doing wrong? How can I debug a program using a serial connection?
Related
using the files I used before, to connect to arm64 board, I tried this.
etri#abss4:~/rrr/u-boot$ cat gdb_script
target remote localhost:3333
set remotetimeout 10
monitor system_init
monitor sleep 2000
monitor soft_reset_halt
load
b main
b board_init_r
and the command is like this.
ddd --debugger aarch64-none-elf-gdb ~/U-BOOT/u-boot/spl/u-boot-spl.elf
I'm not sure if the debugger counter part in the FPGA is working yet.
By the way, the program (u-boot-spl.bin) is loaded to 0x400_0000 by another program and the linker made the .text start at 0x400_0000. I can see the source files in the ddd window.
I see in the telnet window,
accepting 'gdb' connection from 3333
dropped 'gdb' connection
What am I doing wrong??
Im trying to attach DDD to gdb on a remote machine. I have configured rsh to not require a pass for my machine & username.
ddd opens with "rtx5:1234: not found" and a pop-up with "GDB could not be started". From calling ddd --host rtx5:2159 --trace --no-exec-window /home/murray/beer-process
# Running GDB (pid 2826, tty /dev/pts/1)...
# Current language: C/C++
# Searching "vsllib/ddd.vsl"...
# Trying "/home/murray/.ddd/vsllib/ddd.vsl"
# Trying "/usr/share/ddd-3.3.12/vsllib/ddd.vsl"
# Searching "vsllib/ddd.vsl"..."/usr/share/ddd-3.3.12/vsllib/ddd.vsl".
<- "sh: line 0: exec: rtx5:2159: not found\n"
# Running GDB (pid 2826, tty /dev/pts/1)...Exit 127.
The PID of GDB started by ddd from the trace logs are 4-digits. However, all the PIDs that I can see from the rtx(target) are 8-digit. I can not see gdb as a process yet the trace log indicates otherwise. Is the documentation out of date and I am invoking it incorrectly? How could I test if ddd is correctly rsh-ing?
I have addressed the caveats of the docs 2.4.1:
Beer-process binary is in the home dir of my username on the target.
Checked the path of gdb in /usr/bin/gdb
rtx5 does not have xterm therefore include --no-exec-window flag
Thanks in advance
TLDR: Had a firewall on the host interfering only with ddd's rsh connection. I also had to substitute "rtx5" for "'rsh rtx5'". It wont find the program I pass it, even though its in the home directory of the remote target. I can however use ddd-gui to find, load, and debug it.
I could rsh to rtx5 without a password, then call gdb.
I could not do "rsh rtx5 gdb" and have gdb start. This is due to rsh. When rsh is called without a command it operates out of 514. If rsh in called with a command it communicates and attempts to move to a different port number. This is where my firewall was blocking it.
Wireshark showed me from local to target after rsh connection:
destination unreachable (host administratively protected)
ddd still has issues primarily that I can not load a binary which is in my remote home directory. This extends problem extends to attaching to running processes on the remote host. In both cases I can load/connect via the gui once the connection is established.
Furthermore I have to call ddd with 'rsh ' prepended to the remote-host name. This seems wrong. I'll update when I have more.
I am remote debugging a Stellaris Launchpad. I use OpenOCD to connect to the stellaris and then connect GDB to the server provided by openOCD. I use Open On-Chip Debugger 0.10.0-dev-00002-g79fdeb3 (2015-07-09-23:28). GDB is the one from arm-gcc-none-eabi, the 4_9-2015q1 release.
I invoke openOCD like this:
/usr/local/bin/openocd --file \
/usr/local/share/openocd/scripts/board/ek-lm4f120xl.cfg \
>> openocdLog.txt 2>&1 &
And then GDB like this:
arm-none-eabi-gdb proj//debug/exec -x gdb//gdb.script
gdb/gdb.script contains:
set remotetimeout 10000
target extended-remote :3333
monitor reset halt
load
monitor reset init
The problem is that whenever I hit control+c GDB disconnects. Normally this would halt the remote, but GDB just disconnects:
(gdb) cont
Continuing.
^CError detected on fd 6
Remote communication error. Target disconnected.: Interrupted system call.
(gdb)
OpenOCD has the following things to say, this one while GDB is launching:
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258). Workaround: increase "set remotetimeout" in GDB
Which is weird, considering the gdb/gdb.script file forces remotetimeout to an insanly large number.
And when pressing control+c openOCD says:
Debug: 2602 5089 hla_interface.c:119 hl_interface_quit(): hl_interface_quit
So, how do I resolve this? How can I make GDB halt the remote instead of disconnecting when pressing control+c?
The problem was OpenOCD being too bleeding edge. I had issues with 0.6.1, but version 0.7.0 of OpenOCD works great.
I have:
A proprietary prototype ARM board (Cortex-M3 based) with eCos OS
The board has the programmed RedBoot bootloader
Serial line (RS-232)
GDB debugger for ARM (arm-eabi-gdb)
Host OS is Windows/Cygwin and/or Linux (actually, doesn't matter)
Problem: GDB debugger cannot connect to the target over the serial line.
What I want: is to sniff the packets of the GDB remote protocol in order to undestand whether the GDB stub on the target is alive and operating.
Details: RedBoot has an option to pass the target's control to the built-in GDB stub. I know that the RedBoot is alive, I can connect to it and send it commands over the serial line. The RedBoot manual says that the switch to the GDB stub can be made by typing $ or + symbols (which are actually the prefixes of the GDB remote protocol packets). It seems to work for when I send those symbols the terminal dies. But I'm not sure if the RedBoot was compiled with the GDB stub support (don't ask me why :-)).
Then, when I try to connect to the board with my GDB debugger I get the following picture (on Windows):
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
The port is correct, the baudrate as well. Actually the same output I get if I try to do the same with another serial port which is not connected with anything.
What I want to know is does GDB stub send back anything or not?
Intuitively I thought that probably
set verbose on
would help, but GDB manual says it has very a limited effect and my case is beyond it.
May be it is possible to compile GDB debugger with a macro which enables debug logging?
What I want to know is does GDB stub send back anything or not?
Do this (before target remote):
(gdb) set debug remote 1
I'm using GDB and OpenOCD to debug a simple program on my STM32F4DISCOVERY board on Windows. This works fine when starting OpenOCD separately, and using TCP/IP to connect to it, with something like this:
target remote localhost:3333
When I'm done, I can shut down GDB using quit as normal. I would like, however, to use GDB in "remote pipe" mode, instead of needing to start and stop OpenOCD manually. This seems like a somewhat ideal configuration to me. When I do this, however, I cannot exit GDB, as it hangs when I attempt to exit.
The OpenOCD log file shows that the GDB connection was dropped:
Info : dropped 'gdb' connection
But GDB never exits:
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be detached.
Quit anyway? (y or n) y
Detaching from program: yagarto_sample.elf, Remote target
Ending remote debugging.
The disconnect command similarly hangs, never returing. Not even Ctrl-C will wake up GDB.
It turns out there is a bug in OpenOCD related to a change made by GDB. A bit of detail is here, and a patch has been submitted, and a workaround is provided:
Add this to your cfg:
$_TARGETNAME configure -event gdb-detach { shutdown }
I tested this workaround, and it does work, but in the end, pipe mode is so slow on Windows that I chose to use TCP, even though it is less convenient.