qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [6095] User-mode GDB stub improvements - handle fork


From: Laurent Desnogues
Subject: Re: [Qemu-devel] [6095] User-mode GDB stub improvements - handle fork
Date: Tue, 6 Jan 2009 18:27:16 +0100

On Tue, Jan 6, 2009 at 5:19 PM, Martin Mohring
<address@hidden> wrote:
[...]
> Aurelien Jarno wrote:
>> Revision: 6095
>>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6095
>> Author:   aurel32
>> Date:     2008-12-18 22:44:04 +0000 (Thu, 18 Dec 2008)
>>
>> Log Message:
>> -----------
>> User-mode GDB stub improvements - handle fork
>>
>> Close gdbserver in child processes, so that only one stub tries to talk
>> to GDB at a time.  Updated from an earlier patch by Paul Brook.
>>
>> Signed-off-by: Daniel Jacobowitz <address@hidden>
>> Signed-off-by: Aurelien Jarno <address@hidden>
>>
>> Modified Paths:
>> --------------
>>     trunk/gdbstub.c
>>     trunk/gdbstub.h
>>     trunk/linux-user/main.c
>>     trunk/linux-user/syscall.c
>>
>> Modified: trunk/gdbstub.c
>> ===================================================================
>> --- trunk/gdbstub.c   2008-12-18 22:43:56 UTC (rev 6094)
>> +++ trunk/gdbstub.c   2008-12-18 22:44:04 UTC (rev 6095)
>> @@ -1996,6 +1996,18 @@
>>      gdb_accept();
>>      return 0;
>>  }
>> +
>> +/* Disable gdb stub for child processes.  */
>> +void gdbserver_fork(CPUState *env)
>> +{
>> +    GDBState *s = gdbserver_state;
>> +    if (s->fd < 0)

Other qemu gdb functions do this:

    if (gdbserver_fd < 0 || s->fd < 0)

>> +      return;
>> +    close(s->fd);
>> +    s->fd = -1;
>> +    cpu_breakpoint_remove_all(env, BP_GDB);
>> +    cpu_watchpoint_remove_all(env, BP_GDB);
>> +}
>>
> In case of USE_NPTL is defined, it seems that either s or env can be
> NULL, so I get a exception (yes, nptl works on arm in user mode).
> My understanding is that this might be a race condition of the first
> fork() call coming even before env or gdbserver_state is initialised
> towards !NULL.

Could you check if my proposed change above fixes your issue?


Laurent




reply via email to

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