qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Avoid segfault in cpu_dump_state


From: Fabien Chouteau
Subject: Re: [Qemu-devel] [PATCH] Avoid segfault in cpu_dump_state
Date: Wed, 30 May 2012 10:07:56 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 05/30/2012 09:58 AM, Alexander Graf wrote:
> 
> On 23.05.2012, at 17:43, Fabien Chouteau wrote:
> 
>> On 05/16/2012 03:39 PM, Fabien Chouteau wrote:
>>> On 05/16/2012 10:29 AM, Fabien Chouteau wrote:
>>>> On 05/16/2012 05:50 AM, Andreas Färber wrote:
>>>>> Am 15.05.2012 18:08, schrieb Fabien Chouteau:
>>>>>> On 05/15/2012 03:31 PM, Andreas Färber wrote:
>>>>>>> Am 15.05.2012 11:39, schrieb Fabien Chouteau:
>>>>>>>> Do not call cpu_dump_state if logfile is NULL.
>>>>>>>
>>>>>>> And where is log_cpu_state() being called from? Its caller is passing
>>>>>>> NULL already then.
>>>>>>>
>>>>>>
>>>>>> No, logfile is a global variable. log_cpu_state() takes only CPUState
>>>>>> and flags parameters.
>>>>>
>>>>> Ah, I see now that f is a different f here, logfile becomes
>>>>> log_cpu_state()'s f. Unfortunate naming.
>>>>>
>>>>> Your fix looks OK then but I would recommend turning it into a static
>>>>> inline function to avoid the line breaks.
>>>>>
>>>>
>>>> In this case I can rewrite all the macros in qemu-log.h to static inline.
>>>>
>>>
>>> This is more complex than expected...
>>>
>>> 1 - GCC rejects inlined variadic functions
>>>
>>> 2 - Moving from macro to inline implies use of types defined in cpu.h
>>> (target_ulong, CPUArchState...), which I cannot include because
>>> qemu-log.h is used in tools (i.e.  without cpu.h).
>>>
>>> Conclusion: unless someone volunteer for a massive restructuring of
>>> qemu-log we have to keep the marcro for log_cpu_state.
>>>
>>
>> So, are we good with the second patch?
> 
> No reply, so I assume that's a yes. Applied it to ppc-next :). Thanks a lot!
> 

You're welcome!

Thanks,

-- 
Fabien Chouteau



reply via email to

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