Reputation: 1
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. My setup is working "a little bit". I can set breakpoints and step through the code but at some point the board gets unresponsive and can't continue nor break execution.
I enabled the following configurations for the linux 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.
Upvotes: 0
Views: 78