Jan Kiszka wrote:
> Zhang, Xiantao wrote:
>> From ee96ecb2c86e820278f3332d32a452f31c72dc30 Mon Sep 17 00:00:00
>> 2001 From: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
>> Date: Thu, 27 Nov 2008 17:23:27 +0800
>> Subject: [PATCH] KVM: Qemu: Build fix for !CONFIG_GDBSTUB case.
>>
>> Once CONFIG_GDBSTUB not configured, compile will generate error.
>>
>> Signed-off-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> ---
>> qemu/vl.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/qemu/vl.c b/qemu/vl.c
>> index 92325e6..46733e9 100644
>> --- a/qemu/vl.c
>> +++ b/qemu/vl.c
>> @@ -3862,10 +3862,12 @@ static int main_loop(void)
>> qemu_system_powerdown();
>> ret = EXCP_INTERRUPT;
>> }
>> +#ifdef CONFIG_GDBSTUB
>> if (unlikely(ret == EXCP_DEBUG)) {
>> gdb_set_stop_cpu(cur_cpu);
>> vm_stop(EXCP_DEBUG);
>> }
>> +#endif
>> /* If all cpus are halted then wait until the next IRQ
>> */ /* XXX: use timeout computed from timers */
>> if (ret == EXCP_HALTED) {
>
> This rather looks like a qemu upstream issue. But as no qemu arch
> comes without gdbstub support and this switch is always true, no one
> noticed it.
>
> But why not fixing the core issue, ie. adding gdbstub support, or at
> least some intermediate dummy functions until qemu gains full ia64
> support? That would also allow to clean up the CONFIG_GDBSTUB
> #ifdef'ery from upstream. And it would be the first step towards kvm
> guest
> debugging support for ia64.
Adding the support gdbstub for ia64 should be the best way to go, but no enough resource to do. Jes is working on upshing kvm/ia64 qemu changes to qemu upstream, and should consider the final solution eventually. Since CONFIG_GDBSTUB is used everywhere in current Qemu upstream, so before CONFIG_GDBSTUB is cleanuped, the current patch should be Okay to solve ia64's build issue. Thanks!
Xiantao
--
To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
