Hi guys,
I'm trying to debug a hypervisor program at EL2 on QEMU with gdb, and a few questions coming up.
I can step thru the code at EL1 before hitting the hvc instruction, once that instruction invoked, the gdb hangs.
I read the spec, and follow the man to do the following things: pstate.d is unmasked, and mdscr_el1.kde is on, and mdcr_el2.tde is on.
Then an exception taken in el2 vec table. My question are:
Q1: Do I have to write my own debug exception handler or gdb can handle that automatically?
Q2: Is this not the properly way to debug EL2?
Q2: If I run the OS & Hypervisor on QEMU, is it possible to debug them thru DS-5? (without using Fast Model)
Thanks a lot
Hi,
Can you provide a little more info about the setup?
Are you using qemu in system emulation mode or in virtualization mode on Arm hardware?
Do you know if gdb is the problem or is the software causing the hang? It could be caused by something else like enabling like enabling the Hyp Call in the Secure Configuration Register.
DS-5 can connect to a gdbserver:
https://developer.arm.com/docs/100953/latest/configuring-debug-connections-in-ds-5-debugger/configuring-a-connection-to-a-linux-application-using-gdbserver
The regular use case is gdbserver controlling a Linux application, the gdb connection built into qemu may work the same, but I have not tried it.
I would recommend ruling out qemu and gdb by cross checking with DS-5 and a Fast Model so you can separate software issues from tool and model issues.
Let me now if there is anything specific you would like me to try and confirm.
Thanks,
Jason
Hi Jason,
I'm using qemu in system emulation, on x86 host. I don't think that's because gdb, cause I can gdb another bare metal program in and out el2 even switching between el1 & el2. Also when I debugging the bare metal program, I don't need to set up anything like mdcr_el2, etc I mentioned above. It just works so well :)
I checked that hvc call is enabled in SCR. The hypervisor program and the OSes on top are all running well. Just can't debug any code that runs at EL2, but all the other code (at EL1) are fine.
I'll take a look of connecting gdbserver with ds-5 first see if any progress. Since I don't have enough software stack like network driver on fast model, so it'd be hard to debug with fast model. But I will take that into account whenever there's a chance to do so.
Thanks again
I tried connecting qemu's gdbserver with ds-5, seems ds-5 requires a gdbserver with version 6.8 or later. Is there any options to get ds-5 working with older version?
Thanks
I checked into past versions of DS-5 and even going back a few years doesn't help the problem. The best way forward may be to modify the qemu gdbserver. The error is probably not a version number, but the qemu gdbserver is reporting a packet type as unsupported.
Just to confirm, using DS-5 with a Fast Model doesn't require any hardware or software support. The DS-5 debugger makes a direct connection to the model with full debugging.