qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting clang on windows


From: Pierrick Bouvier
Subject: Re: Supporting clang on windows
Date: Sun, 24 Nov 2024 12:24:39 -0800
User-agent: Mozilla Thunderbird

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:
20241122084923.1542743-1-thuth@redhat.com/">https://lore.kernel.org/qemu-devel/20241122084923.1542743-1-thuth@redhat.com/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]