I'm tring to set hardware breakpoint using gdb hbreak command
hbreak *address
but I'm getting the following error: "No hardware breakpoint support in the target".
Is there anyway to fix this problem?
Try the start command first. GDB often says that when the program has not been started yet even if there is hardware support (this is a very misleading message in this context).
Your hardware may not be supporting hardware breakpoints or perhaps you are out of available hw-breakpoint registers. You can still use software breakpoints as a fix.
Related
I want a comprehensive overview of how the debugging process occurs on a typical x86 machine running Linux operating system; let's say the program used for debugging is gdb. Question #1 : is the process of debugging facilitated by the hardware (or it is implemented completely in software instead?). If so, what architecture features from the instruction set are involved?
The x86 ISA includes a single-byte int3 encoding that's intended for software breakpoints. GDB uses this (via ptrace) by default for breakpoints.
(Why Single Stepping Instruction on X86?)
x86 also has a Trap Flag (TF) in EFLAGS for single-step mode. (https://en.wikipedia.org/wiki/Trap_flag). See also Difference between trap flag (TF) and monitor trap flag?
There are even "debug registers" for setting hardware breakpoints, without modifying the machine code to be run. And also hardware support for watch points, to break on write to a certain address. This makes GDB watch points efficient, not requiring it to single-step and manually decode the instruction to see where it writes.
https://wiki.osdev.org/CPU_Registers_x86#Debug_Registers
Implementing hardware breakpoints using x86 debug register osdev forum thread might be relevant.
Some other ISAs exist without nearly as much HW support for debugging. e.g. without a single-step flag, a debugger might have to always decode the current instruction (pointed to by program counter) to find the next one to be executed, and set a software breakpoint there.
ARM Linux used to do that to implement ptrace single-step, but that disassembler code was removed from the kernel and now just returns -EIO. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=425fc47adb5bb69f76285be77a09a3341a30799e is the commit that removed it.
I am debugging linux ubuntu kernel using kgdb / remote gdb. I have 2 computers - ubuntu target and windows host. Computers are connected using serial port and null-modem cable.
KGDB support is enabled in target ubuntu system, command options fro KGDB:
kgdbwait kgdboc=ttyS0,115200
On my Windows system i have MinGW gdb build (x86_64):
GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc.
This GDB was configured as "x86_64-w64-mingw32".
I start my target system and it waits till remote debugger connection. I enter the following commands in GDB window:
(gdb) set remotebaud 115200
(gdb) target remote COM4
My gdb is able to connect to target and prints the following:
Remote debugging using COM4
???() at kernel/debug/debug_core.c:1043 wmb(); /* Sync point after breakpoint */
I then enter command to set breakpoints to be able to return to gdb when OS is booted:
(gdb) b sys_sync
Breakpoint 1 at 0xffffffff8124a710
I also tried hardware-assisted breakpoints in another run of same setup:
(gdb) hbreak sys_sync
This breakpoint setup should lead to kernel beak back to debuger when i enter sync command from target ubuntu console.
After i hit continue in GDB, OS is booted OK, but i never able to bring control back to gdb. I tried setting breakpoints on sys_sync, i tried
echo g > /proc/sysrq-trigger
in all cases with no success.
Very interesting: if i dont initially set breakpoint in sys_sync, entering sync command later does nothing. If i set sys_sync breakpoint, entering sync command later do halt target computer completely - so i suppose breakpoint actually set in this case.
How to break into debugger? GDB becomes irresponsive to any CTrl-C commands, so no way to continue debuging after i initially hit continue.
May be architecture incompatibility (Windows gdb - Linux target) - but seems like breakpoints are really set.
Please help
On your Test machine: login as a superuser.
sudo su
and after that generate a sysrq-trigger
echo g > /proc/sysrq-trigger
After this your target machine should freeze but the dev machine should break into target.
Lower the baud rate on both ends. In my experience, while the 115200 baud rate is theoretically supported, it rarely works properly. I recommend dropping the baud rate down to 9600 (on both ends), and finding success. Once that is achieved, then you can step the speed back up one step at a time. I am rarely able to get the kgdb to work reliably beyond 34K baud, and often lower. And I have also made sure to use the proper RTS/CTS cross linked connectors, some store bought, and some hand-made. It never matters, I think the problem is some issue in kgdboc on the SUT side that does not really always work at full 115200 baud rate. Solution is just to lower the baud rate to 9600. The data is small, so the lower speed does not hurt anything, and having it work reliably is worth any speed penalty.
I am compiling a linux distribution(openwrt) for beaglebone-black and getting the following o/p on my serial port
uncompressing Linux....done,booting the kernel(kernel hangs) in order to trace the error i have enabled CONFIG_DEBUG_LL=y(enables the low level debuging) and CONFIG_DEBUG_INFO=y(enables kernel debug information) but i found CONFIG_DEBUG_LL_UART_NONE=y so if i am correct this means the platform does not support UART debugging(even though kernel is giving the information i might not be seeing that) so is there any other way to debug the kernel or enable the serial port on beagle bone black? if any 1 can guide me through that it would be a great help.....
thanks,
If you have a debugger, then you can certainly debug why your kernel is not booting up.
Assuming, you have one, do the following:
In Kernel configuration, enable CONFIG_DEBUG_INFO (Kernel Hacking ->
Compile-time checks and compiler options)
Compile the kernel
From the debugger software, load the symbols from the elf. The
command varies from one debugger to another
Find symbol "log_buf", and chose option to "Display memory as dump"
There you can see the kernel logs that are not yet printed but stored in the buffer. Hope it helps!
I am getting a General protection error while I run a binary. But there is no core dump. How do I debug the problem ?
Is this the problem with the "ld" i am using ?
kernel: testbin[24879] general protection ip:7fd7271585e0 sp:7fff1ef55070 error:0 in ld-2.14.so[7fd727142000+20000]
Before debugging, re-compile your program with debugging symbols (-g option), else you wont have enough detail information to effectively and quickly debug it (like filename, function, line).
There are more programs for debugging programs but for now I will suggest you valgrind.
So run your program through valgrind:
valgrind /path/to/your/program
and then reproduce steps to cause your program to General Protection Fault.
If the software isnt yours, you'll have to contact the author and get support.
I am writing an editor in assembly 64bit mode in linux. It runs correctly when I debug the program in GDB but it does not run correctly when I run it normally it means it has runtime errors when I use ./programName .
You're probably accessing uninitialized data or have some kind of memory corruption problem. This would explain the program behaving differently when run in the debugger - you're seeing the results of undefined behavior.
Run your program through valgrind's memcheck tool and see what it outputs. Valgrind is a powerful tool that will identify many runtime errors on Linux, including a full stack trace to the error.
If GDB disabling ASLR is what makes it work, perhaps set disable-randomization off in GDB will let your reproduce a crash inside GDB so you can debug it. Force gdb to load shared library at randomized address.
Otherwise enable core dumps from your program, and use GDB on the core dump.
gdb ./prog core.1234.
On x86, you can insert a ud2 instruction in your asm source to intentionally cause a crash at whatever point you want in your code, if you want to get a coredump to examine registers/memory at some point before it crashes on its own. All architectures have an undefined instruction you can use, but I only know the mnemonic for x86's off the top of my head.