qemu-devel
[Top][All Lists]
Advanced

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

Re: dangers of current NEED_CPU_H, CONFIG_SOFTMMU, CONFIG_USER_ONLY


From: Claudio Fontana
Subject: Re: dangers of current NEED_CPU_H, CONFIG_SOFTMMU, CONFIG_USER_ONLY
Date: Fri, 18 Dec 2020 01:14:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 12/18/20 12:47 AM, Claudio Fontana wrote:
> On 12/17/20 11:49 PM, Peter Maydell wrote:
>> On Thu, 17 Dec 2020 at 22:45, Claudio Fontana <cfontana@suse.de> wrote:
>>>
>>> On 12/17/20 9:15 PM, Peter Maydell wrote:
>>>> On Thu, 17 Dec 2020 at 19:46, Claudio Fontana <cfontana@suse.de> wrote:
>>>> Yeah, don't try to ifdef out struct fields in common-compiled code...
>>>
>>> or should I? Using
>>>
>>> #ifdef NEED_CPU_H
>>> #ifdef CONFIG_SOFTMMU
>>>
>>> seems to do what I expect. Is it wrong?
>>
>> I think that gives you two versions of the struct:
>> - one seen by compiled-once files and by compiled-per-target softmmu files
>> - one seen by compiled-per-target user-only files
>>
>> Since the user-only target executables link both compiled-per-target
>> and compiled-once files I think they end up with different C files
>> thinking the same struct has a different layout/size which seems
>> like it's going to cause problems.
>>
>> thanks
>> -- PMM
>>
> 
> It doesn't with
> 
> #ifdef NEED_CPU_H
> #ifdef CONFIG_SOFTMMU
> 
> just double checked the pointers from both files compiled per target and 
> "common"; also all tests are ok.
> 
> It immediately breaks if I replace those two defines with #ifndef 
> CONFIG_USER_ONLY and recompile.
> 
> I thought it was by design, but I guess this is just a "lucky" accident?

By lucky accident I mean that CONFIG_SOFTMMU is a check in the positive instead 
of the #if !defined(CONFIG_USER_ONLY), so it ends up working..

> 
> Ciao,
> 
> Claudio
> 




reply via email to

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