I’m trying to cross debug the linux kernel on a ARM target and a x86_64 host. I am using PetaLinux, which uses Yocto Linux internally, to build the linux image. I have enabled debug information and kgdb for the kernel:

CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB=y
CONFIG_FRAME_POINTER=y

At first, I register the kgdboc module:

echo ttyPS0 > /sys/module/kgdboc/parameters/kgdboc

Then, I trigger a breakpoint:

echo g > /proc/sysrq-trigger

Now, i close minicom and i connect with gdb using the cross gdb used by PetaLinux (aarch64-linux-gnu-gdb):

$ aarch64-linux-gnu-gdb vmlinux
(gdb)set serial baud 115200
(gdb)set debug remote 1
(gdb)set architecture armv7
(gdb)set substitute-path /usr/src/debug/linux-xlnx/6.1.30-xilinx-v2023.2+git999-r0 /home/test/repos/linux-xlnx
(gdb)target remote /dev/ttyACM0

I’m able to continue, set breakpoints and step through the code.

I tested the debugging by setting breakpoints in the kernel code which i could trigger from the commandline. In particular, I set a breakpoint at meminfo_proc_show, which can be triggered by executing cat /proc/meminfo from the target. I can step through the code until the following instruction is executed:

│   0xc02ae480 <meminfo_proc_show+68>       bl      0xc082ca80 <memset>

A branch link to memset. Memset for ARM is defined in the linux kernel in assembly. Using objdump in vmlinux, i can confirm that memset is present in the kernel binary. Additionally, normal execution of the function does not halt the cpu. When I set a breakpoint right after the bl memset instruction and continue, the execution stops at the breakpoint right after the bl memset instruction. The problem only occurs when i stepi/nexti over the bl memset instruction. I enable set debug remote 1 to have a more verbose log. This is the log after stepi of bl memset:

(gdb) si
Sending packet: $Z0,c02ae43c,4#6b...Ack
Packet received: OK
Sending packet: $Z0,c02ae474,4#40...Ack
Packet received: OK
Sending packet: $Z0,c02ae484,4#41...Ack
Packet received: OK
Sending packet: $mc02ae470,4#f3...Ack
Packet received: 82f915eb
Sending packet: $mc02ae470,4#f3...Ack
Packet received: 82f915eb
Sending packet: $mc082ca80,4#f6...Ack
Packet received: 033010e2
Sending packet: $mc02ae470,4#f3...Ack
Packet received: 82f915eb
Sending packet: $mc02ae470,4#f3...Ack
Packet received: 82f915eb
Sending packet: $mc02ae470,4#f3...Ack
Packet received: 82f915eb
Sending packet: $Z0,c082ca80,4#3f...Ack
Packet received: OK
Sending packet: $c#63...Ack

Some breakpoints are set and the execution is continued, but the execution never stops. From here, the board is not responsive and cannot break/continue the board from gdb. After a while, the board reports that the cpu has halted.

I tried different GDB version (including the latest one), different combinations of Kconfig config entries, having the debug information in seperate files, KGDB over ethernet.

But as soon as I encounter the bl memset, the board gets unresponsive. I noticed that other branch and link instructions trigger the same behaviour (only the ones which branch to a location which is far away). Other branch instructions work fine.

When I was looking for alternatives, I found out that debugging via QEMU and its builting gdb works flawlessly, but i would like to debug actual hardware.

Can anyone help me? Is the KGDB setup wrong? I have no idea how to continue from here.