armv8 qemu_cortex_a53 bug(gdb) on official sample

[cocoeoli]

Describe the bug
When I run zephyr.elf file(below information is based on basic demo: sample/hello_world) on qemu_cortex_a53 platform and try to debugging it using below command:
run zephyr.elf file command:
../zephyr$ qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic -kernel zephyr.elf -S -s
debug it command:
../zephyr$ gdb-multiarch -q -ex 'file zephyr.elf' -ex 'target remote localhost:1234'

When I input 'continue' command in gdb, the gdb always loss response. So I have to type ' ctrl + c ' to create a signal and I find it trap to an loop in ../zephyr/kernel/fatal.c file, the loop code is below:

FUNC_NORETURN __weak void arch_system_halt(unsigned int reason)
{
	ARG_UNUSED(reason);

	/* TODO: What's the best way to totally halt the system if SMP
	 * is enabled?
	 */
	(void)arch_irq_lock();
	for (;;) {                                         //trap to this loop
		/* Spin endlessly */
	}
}

So I try to degub it to find what cause the trap and i find it is because the below asm code:
ldr w1 [x2]
related c code is:

static void gicv3_rdist_enable(mem_addr_t rdist)
{
	if (!(sys_read32(rdist + GICR_WAKER) & BIT(GICR_WAKER_CA)))     //this line will cause trap!
		return;
	sys_clear_bit(rdist + GICR_WAKER, GICR_WAKER_PS);
	while (sys_read32(rdist + GICR_WAKER) & BIT(GICR_WAKER_CA))
		;
}

And I find the value of 'x2' is 0x80a0014 ,the address is the gic device memory, it is allocated to gic device when system init mmu. Then I check the Arm architucture Reference Manual and find the reason why the code will trap to the loop is descripte below:

Used for MMU faults generated by data accesses, alignment faults other than those caused by Stack Pointer misalignment, and synchronous External aborts, including synchronous parity or ECC errors. Not used for debug-related exceptions.

It all seem that it is a memoy access error. It is inportent that what bothers me is that when I run the zephyr.elf without debug , it work well. But when I try to debug it and type 'continue' in gdb, it always trap to this loop!!
I want to know why and try to solve it!
Thanks for your reply.

Environment (please complete the following information):
Official development environment.
@carlocaione

[stephanosio]

Unable to reproduce -- when I tested this locally using the Zephyr SDK 0.13.2, without any breakpoints set, the GDB breaks somewhere in cpu_idle.S as expected when CTRL+C is pressed.

It seems you are using a third-party QEMU and GDB that may not be of a compatible version and/or do not have the required Zephyr-specific patches applied.

Please use the QEMU and GDB from the Zephyr SDK.

[cocoeoli]

Thanks to your reply.
But I can't find the command that debug my demo on qemu_cortex_a53 platform, west build seems does't work well.

ninja: no work to do.
FATAL ERROR: either a pristine build is needed, or board qemu_cortex_a53 doesn't support west flash/debug (no ZEPHYR_RUNNERS_YAML in CMake cache)

Could you please tell me where can I find a tutorial to debug my code using Zephyr SDK on qemu_cortex_a53 platform?

[stephanosio]

Try west debugserver to launch QEMU GDB server, and connect to it from the aarch64-zephyr-elf-gdb provided in the Zephyr SDK (unfortunately, west debug, which automatically launches the GDB, is not supported at the moment for the QEMU targets; see #35366).

[cocoeoli]

Oh! It seems that 'west debugserver' is not supported too. The error message is the same as before.

[carlocaione]

Try west build -t debugserver

[cocoeoli]

Thanks! west build -t debugserver can work well. And when I test other command like ninja debugserver in ../zephyr/build dir, it can work too. In addtion, I find that when I run command ninja debugserver, the running command is:
../path/to/qemu-system-aarch64 -M virt,secure=on,gic-version=3 -net none -pidfile qemu.pid -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -cpu cortex-a53 -nographic -kernel ../path/to/zephyr.elf -S -s
So I try to add above qemu's command using original qemu(not from Zephyr SDK), then using original gdb to debug it, and it can work well too.
Therefore, I think the problem is with the qemu's command(maybe: gic-version=3 or -mon chardev=con,mode=readline ), not the qemu or gdb's version.
In general, thank you again for you helping me solve this issue.