Re: Supporting clang on windows

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

On 11/24/24 04:28, Philippe Mathieu-Daudé wrote:
> On 24/11/24 01:21, Pierrick Bouvier wrote:
>> Hi all,
> 
> 
>> 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 *MachineClass ones come from [*]:
> 
>     struct MachineClass {
>         ...
>         unsigned int no_serial:1,
>             no_parallel:1,
>             no_floppy:1,
>             no_cdrom:1,
>             no_sdcard:1,
>             pci_allow_0_address:1,
>             legacy_fw_cfg_order:1;
> 
> IMHO Using bitfield to manually micro-optimize memory size seems
> a bit a waste of developer time/focus, I'd rather see compilers
> doing that for us.
> 

Yes, it's (another) lesson that C bitfields are a good synonym of non 
portable code in general.

> Regards,
> 
> Phil.
> 
> [*] Interestingly Thomas is also looking at those fields:
>   
> https://lore.kernel.org/qemu-devel/20241122084923.1542743-1-thuth@redhat.com/