qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Build broken


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Build broken
Date: Fri, 5 Aug 2011 10:37:24 +0100

On Fri, Aug 5, 2011 at 10:09 AM, Kevin Wolf <address@hidden> wrote:
> Am 05.08.2011 10:48, schrieb Stefan Hajnoczi:
>> On Fri, Aug 5, 2011 at 8:29 AM, Kevin Wolf <address@hidden> wrote:
>>> Am 05.08.2011 08:22, schrieb malc:
>>>>
>>>> /home/malc/x/rcs/git/qemuorg/coroutine-ucontext.c: In function 
>>>> 'coroutine_new':
>>>> /home/malc/x/rcs/git/qemuorg/coroutine-ucontext.c:160:16: error: 
>>>> 'arg.i[1]' may be used uninitialized in this function
>>>> /home/malc/x/rcs/git/qemuorg/coroutine-ucontext.c:136:18: note: 'arg.i[1]' 
>>>> was declared here
>>>>
>>>> diff --git a/coroutine-ucontext.c b/coroutine-ucontext.c
>>>> index 41c2379..42dc3e2 100644
>>>> --- a/coroutine-ucontext.c
>>>> +++ b/coroutine-ucontext.c
>>>> @@ -133,7 +133,7 @@ static Coroutine *coroutine_new(void)
>>>>      CoroutineUContext *co;
>>>>      ucontext_t old_uc, uc;
>>>>      jmp_buf old_env;
>>>> -    union cc_arg arg;
>>>> +    union cc_arg arg = {0};
>>>>
>>>>      /* The ucontext functions preserve signal masks which incurs a system 
>>>> call
>>>>       * overhead.  setjmp()/longjmp() does not preserve signal masks but 
>>>> only
>>>>
>>>> I guess gcc should yell not only here on ppc32 but on any machine where
>>>> pointer size is less than the size of two ints.
>>>
>>> Stefan, why does this code even exist again? I think at some point I had
>>> it changed to just use a static variable in order to avoid doing this
>>> kind of tricks with unions.
>>
>> virtfs are using coroutines in multiple threads at the same time.
>> Introducing a global variable wouldn't be thread-safe.
>>
>> The real problem is that makecontext(3) has a bad function signature.
>> There's no nice fix - whatever we do will be ugly.
>>
>> Using a union is the way it should be done in C.  The code doesn't
>> look pretty but it doesn't introduce global state.
>
> But it makes assumptions about the pointer size, which isn't a nice
> thing. TLS isn't an option for compatibility with some OSes/architectures?

GThread TLS is portable but slow in my testing.

You are right, when we move to 128-bit pointers this code will break
:).  We could at add a #warning if pointer size > 64-bits.

Stefan



reply via email to

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