qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 0/1] Fix GDB semihosting


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v1 0/1] Fix GDB semihosting
Date: Thu, 16 Feb 2012 19:08:36 +0000

On 16 February 2012 18:39, Meador Inge <address@hidden> wrote:
> On 02/15/2012 02:14 PM, Peter Maydell wrote:
>> I think the right way to deal with both the problem you were seeing
>> and this related issue is simply not to try to send the syscall
>> request until we have really stopped the CPU. That is, when not
>> in CONFIG_USER_ONLY we should send the syscall request from
>> gdb_vm_state_change().
>
> I agree.  I am doing some more testing and will send an official v2 patch
> later, but just to make sure I am on the right track something like (this
> worked in the basic testing I have done so far and avoids the pitfall pointed
> out above):

That looks roughly OK, but:
 * shouldn't gdb_syscall_buf[] be in GDBState ?
 * I don't think the "are we stopping to do a syscall?" flag should be
   implemented as an RSState enum -- that enum is for the
parsing-incoming-packet
   state machine

Bonus extra semihosting bug: if you start with "-gdb none" rather than "-s" then
we segfault, because gdbserver_start() creates a GDBState with a NULL s->chr
but use_gdb_syscalls() only looks at whether gdbserver_state is non-NULL, not
whether s->state is RS_INACTIVE, so the first gdb_do_syscall() ends up
dereferencing that NULL pointer. (Watch out when fixing this that you don't
break semihosting in linux-user mode, because at the moment linux-user mode
doesn't set up s->state at all so it's always RS_INACTIVE... We may also
want to declare that mixing all of gdb, semihosting and fork() in a linux-user
guest is not supported ;-))

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]