On 11/24/24 23:00, Paolo Bonzini wrote:
On Sun, Nov 24, 2024 at 9:23 PM Pierrick Bouvier <[email protected]> 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
