Hi all,
very recently, I've been working on enabling clang builds on Windows
[1]. As part of it, the major blocking point is that currently, clang
does not support gcc_attribute on Windows.
The change proposed [2] was to use the compiler option [3]
-mno-ms-bitfields, which enables the same behaviour. This option *only*
has an effect on structs containing bitfields or structs that are
packed, not on *all* structs.
The question that was left is: Is it was we want?
After thinking about it, a simple, exhaustive and reliable way to find
this type information is the debug (dwarf) info.
By compiling qemu binaries with --enable-debug, and extracting info
using llvm-dwarfdump plus a custom filter [4], we can obtain a text
representation of all structures QEMU uses.
As expected, turning the option globally has an effect. The exact list
of structures impacted (those having bitfields, and not being packed)
can be seen for each binary here: [5].
As there is a lot of repetition between all qemu binaries, the reduced
list of structs concerned is [6]:
+name:ArduinoMachineClass size:0x0198
+name:ARMCacheAttrs size:0x04
+name:ARMVAParameters size:0x04
+name:AspeedMachineClass size:0x01d0
+name:_GIOChannel size:0x70
+name:MachineClass size:0x0188
+name:MicrovmMachineClass size:0x01a0
+name:MPS2MachineClass size:0x01a8
+name:MPS2TZMachineClass size:0x01e8
+name:MPS3RMachineClass size:0x01a0
+name:MuscaMachineClass size:0x01a8
+name:NPCM7xxMachineClass size:0x0190
+name:PCMachineClass size:0x01c0
+name:PnvMachineClass size:0x01b0
+name:PPCE500MachineClass size:0x01e0
+name:RaspiBaseMachineClass size:0x0190
+name:RxGdbSimMachineClass size:0x0198
+name:S390CcwMachineClass size:0x0190
+name:SpaprMachineClass size:0x01d0
+name:Sun4mMachineClass size:0x0190
+name:TriBoardMachineClass size:0x01a0
+name:VexpressMachineClass size:0x0190
+name:VirtMachineClass size:0x01a0
+name:X86MachineClass size:0x0190
The interesting point I discovered is that, *after* this change, the new
size start to match size when compiling for Linux.
After all, it makes totally sense: gcc by default mimics MSVC behaviour
for bitfields, which is different from its behaviour on Linux.
As a conclusion, I think that applying gcc_struct selectively is a wrong
default, and using globally the -mno-ms-bitfields allows to mimic what
gcc is doing on Linux. We don't need any ABI compatibility with MSVC, so
it's safe to enable this.
Before pushing the change again in a new series, I would like to get
feedback from the concerned developers, and hope it can convince you
this time it's a better approach than what we have.
As a side effect of all this, it will unlock supporting clang on
windows, and with that, building it officially for windows-arm64, which
was one of the goal of the original series.
Regards,
Pierrick
[1]
https://lore.kernel.org/all/[email protected]/
[2]
https://lore.kernel.org/all/[email protected]/
[3] https://gcc.gnu.org/onlinedocs/gcc/x86-Variable-Attributes.html
[4]
https://github.com/pbo-linaro/qemu_packed_structs/blob/master/filter_dwarf_dump.sh
[5]
https://github.com/pbo-linaro/qemu_packed_structs/commit/a47747b5220a933a94dbdc6e7bcd96589ae9abd0
[6]
https://github.com/pbo-linaro/qemu_packed_structs/commit/9d41b7bd1fbd1d1553ae532e36c9305438549ae4
