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.
Related
I have a setup with openocd and arm-none-eabi-gdb and I'm trying to debug a FreeRTOS fw.
I start openocd with:
openocd -f /usr/local/share/openocd/scripts/board/stm32f0discovery.cfg -c "stm32f0x.cpu configure -rtos auto"
That command works fine.
Then I run arm-none-eabi-gdb -tui and at the end of my .gdbinit I have:
target remote localhost:3333
monitor reset halt
file build/fw.elf
load
continue
focus next
But when I try to stop <ctrl>-c and start continue my fw all I get is the error:
Cannot execute this command without a live selected thread.
What am I missing?
I'm using a JLink Base debug probe.
My case is a bit different than yours, with a setup using QtCreator and its Baremetal plugin, but found a bug report where they state a workaround:
https://bugreports.qt.io/browse/QTCREATORBUG-18436
The workaround is pretty easy:
in GDB Init commands add "info threads" after load command. It fixes issue.
I tried it, and it worked, the error message was removed, and now I can see the different tasks in FreeRTOS.
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?
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.
I am trying to debug Linux kernel with kvm vm. I am getting an error message "Remote 'g' packet reply is too long". My host is 64-bit and so is my vm.
My steps:
Start the VM with custom -kernel, -initrd and -append options.
Start gdb
Execute "set architecture i386:x86-64:intel"
Execute "add-symbol-file linux-3.0/vmlinux"
Execute "show arch" to verify its still "i386:x86-64:intel"
Execute "target remote localhost:1234"
Execute "continue"
Press Ctrl+C, I get the above message.
Has anyone faced this problem?
gdb doesn't work well against a cpu that switches between instruction sets at runtime. Wait for the kernel to leave early boot before connecting, and don't use qemu's -S flag.
I also faced same issue, I fixed it by modifying gdbstub.c (in qemu sources) to send 64bit registers always and hinting GDB that architecture is 64bit by passing set arch i386:x86-64
You can check the patch here:
Visit [URL no longer available]
I found a similar problem (& this question) connecting gdb very early in the boot process – as mentioned in other answers, gdb does not very much appreciate the size of registers changing out from under it. This problem can be seen by using set debug remote 1:
(gdb) set debug remote 1
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
...
Sending packet: $g#67...Ack
Packet received: 000000000000000... <~600 bytes>
(gdb) until *0x1000 # at this address we'll be in a different cpu mode
...
Sending packet: $g#67...Ack
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes>
...
Remote 'g' packet reply is too long: 1000008000000000000000000...
(gdb)
Patching gdb to resize its internal buffer when it sees a too-large packet
as found on this issue in the gdb bug tracker (and elsewhere), does indeed work around the problem, as does patching QEMU to only send 64-bit-sized packets. However, the latter solution breaks debugging in non-64-bit-modes, and it seems that the former fix could be incomplete:
It sounds quite wrong to be changing the target behind
GDB's back when GDB is already debugging it. Not just the size
of the g/G packets may change inadvertently, but the layout as well.
If the target description changes with your re-configuration, it
sounds to me like GDB should fetch/recompute the whole target
description. Today, I think that can only be done with a
disconnect/reconnect.
– https://sourceware.org/ml/gdb/2014-02/msg00005.html
The disconnect/reconnect workaround mentioned at the end of the post does appear to work:
(gdb) disconnect
Ending remote debugging.
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
(gdb) info registers
rax 0x80000010 2147483664
rbx 0x0 0
...
I had accidentally omitted the binary name as an argument to gdb. So this worked for me.
$ gdb ./vmlinux
(gdb) target remote localhost:1234
And then got the Output :
Remote debugging using localhost:1234
0xffffffff81025f96 in default_idle ()
The debugger needs vmlinux so make sure you provide it. OP has a different problem, But my answer might help to those who forgot to provide argument to gdb and ended up with the same error message as OP.
Qemu terminated with the log : "QEMU: Terminated via GDBstub" when I tried to connect to QEmu from GDB .
I started the QEMU with the following command in one terminal :
qemu-system-arm -serial telnet:localhost:1235,server,nowait,ipv4 -serial telnet:localhost:1236,server,nowait,ipv4 -serial telnet:localhost:1238,server,nowait,ipv4 -gdb tcp:localhost:1234,server,ipv4 -kernel ./build/final.elf -M versatilepb -nographic -m 256 -S
And then in another terminal I started GDB with the command :
arm-none-eabi-gdb --command=~/.gdbinit
And the file .gdbinit contains the text:
set history save on
set logging on
target remote localhost:1234
load ./build/final.elf
sym ./build/final.elf
b break_virtual
Can you please let me know whats going wrong here?
GDB automagically loads ~/.gdbinit
so when you load .gdbinit via --command=~/.gdbinit
it runs the script twice,
when it gets to the 2nd invocation of target remote localhost:1234
gdb hangs up its initial connection, qemu quits,
then gdb fails to reconnect to it because it is no longer running.
Either get rid of the --command option or rename the file.