memory alignment issues

[cctv130]

There should be a problem with this piece of code. kEightyBitsInBytes should not be equal to 10. Modify this constant to equal 16. Although it is equal to 10 after the compiler is packed on Linux, it is equal to 16 on Windows and remove the attribute of the structure. ((packed)) attribute, so that struct will not have memory alignment operations, union will have memory alignment operations, and both windows and linux will display 16 bytes. On the linux platform, long double occupies 16 bytes, so modify kEightyBitsInBytes=16 is more appropriate, so that we can simulate long double even if Xclang pf80 is enabled on windows. I don't know if my verification is correct, please give your opinion.
There is also a compiled version for Windows, you can test it when you have time.
https://github.com/lifting-bits/remill/files/14559396/remill-lift-17.zip
https://godbolt.org/z/8Tfc7eEhW

[pgoodman]

Is the problem that __attribute__((packed)) does no achieve the desired result of making it 10 bytes in size? The union_ld data structure exists to access fp80 values regardless of padding. It seems as though you've found an issue where our intent (float80_t being 10 bytes) does not match the reality.

[cctv130]

@pgoodman Yes, Linux's longdouble = 16 bytes, but linux nan80_t in math.h outputs 10 bytes after attribute((packed)). I tested it on Windows and it outputs 16 bytes. If Windows also outputs 10 bytes, then attribute((packed)) makes sense.

[pgoodman]

Does #pragma pack(push) and #pragma pack(pop) resolve this problem?

[cctv130]

[cctv130]

@pgoodman If want to align to 10 bytes on windows might want to enable a flag bit like gcc_bitfield in llvm,But this flag bit does not appear to exist at the moment

[cctv130]

@pgoodman You can use a virtual machine to test the exe I compiled to see if there is any problem with the output ir