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. Other branch link instructions also do 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 even tried KGDBoE, which is just KGDB over ethernet instead of console, but i got the same results.


Being desperate, I tried gdb for qemu, which works flawlessly!



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