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

[Meador Inge]

On 02/16/2012 01:08 PM, Peter Maydell wrote:

> 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

I cleaned up these bits.  v2 patch coming up soon.

> 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 ;-))

I will take a look at that one as a separate patch :-)

-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software