Would a good next step be to work out some more details in a document that outlines what process we are using, what we are planning to do and include a set of suggestions as a starting point to see if we can upstream some of the changes to the larger community?
We currently don't have a proper solution for packing. We are tracking the issue here https://issuetracker.google.com/issues/380295845. All our code is public and development is happening on the emu-dev repository: https://android.googlesource.com/platform/external/qemu/+/emu-dev Greetings, Erwin. On Thu, Nov 21, 2024 at 10:47 AM Paolo Bonzini <pbonz...@redhat.com> wrote: > > NB As a general point, we actively block use of clang with Windows > > builds (more strictly in 9.2 now), because it lacks support for the > > 'gcc_struct' annotation that we rely on to guarantee correct ABI for > > structs exposed to guests in particular. > > Ah, good point. This is > https://github.com/llvm/llvm-project/issues/24757 for the general > tracking issue, and https://github.com/llvm/llvm-project/pull/71148 > for a recent PR that attempts to implement this. > > Using -mno-ms-bitfields globally is unsafe because there are probably > Windows API structs that implement it. > > One solution is to add `QEMU_BUILD_BUG_ON(sizeof(...) == ...)` to all > structs in QEMU that use bitfields. That will prove very quickly if > there are issues or not. > > Paolo > > > Many people try to simply remove that #ifdef, mistakenly assuming that > > because the code compiles without warnings, it must be correct. Did > > you have solution for this, as it would be a blocker for enabling > > clang on Windows currently ? > > > > With regards, > > Daniel > > -- > > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > > >
