I use GDBServer to do a remote debug with an ARM11 CPU. The software breakpoint works well, but we i use "hbreak test.c:5" to set a hardware breakpoint, CPU will never stop.
GDB version: 7.3.1
Target CPU: ARM11
Operation:
arm-linux-gdb ./main
(gdb) target remote 192.168.0.1:2345
(gdb) hbreak test.c:5 => HW breakpoint, it doesn't work. but if change to "b test.c:5", it will works
(gdb) c
Does anybody can tell me how to enable hardware debug with GDB7.3.1? Thanks!
Hardware breakpoints can only be manipulated by JTAG probes. GDB cannot access them, unless you have a JTAG probe (which I doubt you have) connected to your device and a software glue (eg OpenOCD), allowing GDB to communicate with the JTAG probe. On pandaboard, for instance, TI recommends those JTAG probes: http://omapedia.org/wiki/PandaBoard_JTAG_Debugging
Related
I'm trying to use GDB to debug Qemu running on m68k architecture. I am attempting to make some changes to Qemu source to add some functionality to m68k support, and I am trying to use GDB to test changes I have currently made. Important to note is that I am using Qemu v5.2.0-rc1, as that is the version of Qemu currently utilized in a larger system that I am concurrently working with. Currently, I am using qemu-system-m68k to run buildroot (uClinux kernel) on that architecture, using the "-s -S" options for gdb. In a separate terminal, I am trying to run GDB on that remote target using (gdb) target remote localhost:1234, but I am getting the following error message:
warning: Architecture rejected target-supplied description
The connection to the uClinux Qemu kernel seems to go okay, but I cannot connect to the remote host.
I have tried finding any possible solutions to this problem, including setting the GDB architecture (currently says i386, not sure if this is right), which does not work. I have no idea how to get GDB running on this m68k Qemu emulated Linux kernel, and any help would be great. Thanks!
The error message means that QEMU's gdb stub sent gdb a description of what the CPU is (mostly a list of registers), and gdb didn't understand it. One common cause of this is trying to debug with a gdb for the wrong architecture.
You need to use a gdb which is aware of the the target architecture. On Ubuntu there is a 'gdb-multiarch' package which has a gdb-multiarch binary that knows about more than just x86. Otherwise you might need to build gdb from source. You can check if your gdb knows about m68k by running it with no arguments and typing the command set arch m68k. If it replies The target architecture is assumed to be m68k then it's OK (and your issue is something more complicated); if it gives you an error (eg Undefined item: "m68k") then you need to use a different gdb.
I am debugging a remote target and it seems like the software breakpoints are not working, however hardware breakpoints do work.
I want to be able to use the stepi command - but gdb seems to insist on using software breakpoints.
Is there a way to force gdb to use hardware breakpoints for stepi?
The target is an ARM STM32 chip debugged through a blackmagic probe.
One solution is to mark the memory region as read only which forces gdb to use hw breakpoints
I.e if my code is running on the addresses 0x8000000-0x8010000 i run
mem 0x8000000 0x8010000 ro
I want to write my own hypervisor for Intel Platform based on an open project and I want understand how to debug it.
I have real stend to debug on, but it reboots at faults and it is hard to find mistake. I've found I could use QEMU/KVM with nested hypervisor to debug it. May be there are any other variants? VMware is hanging with faults, as I understand. On AMD platforms I have used SimNow.
It will be good if the host system will be Windows.
Thank you for advices.
It depends on your flavor. The couple Qemu/GDB is a good start. Here are some useful hints if your host platform is Intel CPU, you can:
start qemu like this : qemu-system-x86_64 -enable-kvm -cpu host -s -S .... Qemu will boot the hypervisor along with its gdbserver and pause it until it receives continue command from gdb.
Start GDB like this: gdb /path/to/hypervisor then, target remote :1234 to attach the gdb to the gdbserver
Use hbreak instead of break, but you have only 4 breakpoints left
From this point, you may continue the debugging as for a simple application
I managed to set up a gdbserver for a Qt application and ran it on a 64-bit Ubuntu computer using:
gdbserver <ip>:20000 ./sampleQtApp
And I tried to connect it to using a remote computer of the same network using GDB as follows:
set architecture i386:x86-64:intel
target remote <ip>:20000
It gives me the following output, and I can not figure out why.
(gdb) target remote 10.9.5.79:20000
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
Remote debugging using 10.9.5.79:20000
Remote register badly formatted: T0506:0000000000000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
here: 00000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
(gdb)
What am I doing wrong here?
What is your gdb/gdbserver version? Try a more recent one. Look also this question.
I would like to debug an embedded system containing gdb remotely using some kind of gui (ie like ddd). The embedded system does not have the sources or build symbols. However my local x windows box has. However the execution must happen on the embedded system. How can I from my development box drive gdb remotely with some gui ?
leds and jtag are not an option.
I think, gdbserver could help you.
On Remote target:
target> gdbserver localhost:1234 <application>
On Host (build machine):
host> gdb <application>
Note that the on target may be stripped off from the symbols. But host may have all the symbols.
gdb> set <path-to-libs-search>
gdb> target remote <target-ip>:1234
gdb> break main
gdb> cont
If this works, get some GDB gui on the host machine and try to replicate the same settings. (I have used SlickEdit and eclipse for this purpose).