Re: Supporting clang on windows

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 11/24/24 23:00, Paolo Bonzini wrote:
> On Sun, Nov 24, 2024 at 9:23 PM Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
> * there is no pushback against clang support, there is pushback
> against asking for a change without understanding the problem
>

Thanks for taking time to share more insights about it.

> As an aside, at https://github.com/msys2/MINGW-packages/pull/21540 you
> said "I think too it's more a FUD argument than a real problem", which
> is a bit too dismissive. If anything it's a case of "once bitten,
> twice shy".
>

There was no intention to have a personal jugdment, not blame anyone, 
and I hope you didn't take it this way. If that's the case, sorry about 
that.

FUD applies when Fear and Uncertainty applies, and it's definitely where 
we are on this - we fear something from a past experience, and we are 
uncertain about the current status. I totally understand that's a very 
hard issue to diagnose when you meet those kind of memory layout bugs.

> I understand that, and I'm asking you to do another experiment. Do not
> change the compile-time options. Instead, change QEMU_PACKED to just
> 
> #define QEMU_PACKED __attribute__((packed))
> 
> and see if any struct definitions (which will all follow the ms_struct
> rules) change. If there are changes, let's examine what they are and
> why my analysis above was incorrect. Fix those cases, add
> QEMU_BUILD_BUG_ON checks only to the affected structs, and once you've
> addressed any differences (if they exist), you can proceed with
> dropping gcc_struct since there will be concrete evidence proving it's
> safe.
>

I didn't expect the issue of our conversation would be to get rid of 
gcc_struct entirely. Thanks for pushing in the right direction.

I answered later on this thread for this, and it's a very positive 
conclusion: no difference was found with/without gcc_struct attribute.

> Paolo
> 

Thanks,
Pierrick