hi, imho it'd be useful to add -mms-bitfields Use native (MS) bitfield layout to the default CFLAGS for mingw. is there objection? of course i we use mingw's gcc for all libs and dll than it's not a problem, but if we use native or precompiled libs or dlls...
On Wed, Nov 19, 2008 at 12:45:34PM +0100, Farkas Levente wrote:
hi, imho it'd be useful to add -mms-bitfields Use native (MS) bitfield layout to the default CFLAGS for mingw. is there objection? of course i we use mingw's gcc for all libs and dll than it's not a problem, but if we use native or precompiled libs or dlls...
Can you post a suggested patch here please.
For reference, here is what the gcc info file has to say about -mms-bitfields:
5.34.3 i386 Variable Attributes -------------------------------
Two attributes are currently defined for i386 configurations: `ms_struct' and `gcc_struct'
`ms_struct' `gcc_struct' If `packed' is used on a structure, or if bit-fields are used it may be that the Microsoft ABI packs them differently than GCC would normally pack them. Particularly when moving packed data between functions compiled with GCC and the native Microsoft compiler (either via function call or as data in a file), it may be necessary to access either format.
Currently `-m[no-]ms-bitfields' is provided for the Microsoft Windows X86 compilers to match the native Microsoft compiler.
The Microsoft structure layout algorithm is fairly simple with the exception of the bitfield packing:
The padding and alignment of members of structures and whether a bit field can straddle a storage-unit boundary
1. Structure members are stored sequentially in the order in which they are declared: the first member has the lowest memory address and the last member the highest.
2. Every data object has an alignment-requirement. The alignment-requirement for all data except structures, unions, and arrays is either the size of the object or the current packing size (specified with either the aligned attribute or the pack pragma), whichever is less. For structures, unions, and arrays, the alignment-requirement is the largest alignment-requirement of its members. Every object is allocated an offset so that:
offset % alignment-requirement == 0
3. Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation unit if the integral types are the same size and if the next bit field fits into the current allocation unit without crossing the boundary imposed by the common alignment requirements of the bit fields.
Handling of zero-length bitfields:
MSVC interprets zero-length bitfields in the following ways:
1. If a zero-length bitfield is inserted between two bitfields that would normally be coalesced, the bitfields will not be coalesced.
For example:
struct { unsigned long bf_1 : 12; unsigned long : 0; unsigned long bf_2 : 12; } t1;
The size of `t1' would be 8 bytes with the zero-length bitfield. If the zero-length bitfield were removed, `t1''s size would be 4 bytes.
2. If a zero-length bitfield is inserted after a bitfield, `foo', and the alignment of the zero-length bitfield is greater than the member that follows it, `bar', `bar' will be aligned as the type of the zero-length bitfield.
For example:
struct { char foo : 4; short : 0; char bar; } t2;
struct { char foo : 4; short : 0; double bar; } t3;
For `t2', `bar' will be placed at offset 2, rather than offset 1. Accordingly, the size of `t2' will be 4. For `t3', the zero-length bitfield will not affect the alignment of `bar' or, as a result, the size of the structure.
Taking this into account, it is important to note the following:
1. If a zero-length bitfield follows a normal bitfield, the type of the zero-length bitfield may affect the alignment of the structure as whole. For example, `t2' has a size of 4 bytes, since the zero-length bitfield follows a normal bitfield, and is of type short.
2. Even if a zero-length bitfield is not followed by a normal bitfield, it may still affect the alignment of the structure:
struct { char foo : 6; long : 0; } t4;
Here, `t4' will take up 4 bytes.
3. Zero-length bitfields following non-bitfield members are ignored:
struct { char foo; long : 0; char bar; } t5;
Here, `t5' will take up 2 bytes.
Rich.
& from what I read here, it does seem that there could be an incompatibility with MSVC-compiled structures:
http://code.google.com/p/cocotron/issues/detail?id=137
Rich.
Richard W.M. Jones wrote:
On Wed, Nov 19, 2008 at 12:45:34PM +0100, Farkas Levente wrote:
hi, imho it'd be useful to add -mms-bitfields Use native (MS) bitfield layout to the default CFLAGS for mingw. is there objection? of course i we use mingw's gcc for all libs and dll than it's not a problem, but if we use native or precompiled libs or dlls...
Can you post a suggested patch here please.
i'm working on a bigger patch set (unfortunately i've got only one day/week:-(). but this was just a question before the patches.
On Wed, Nov 19, 2008 at 12:45:34PM +0100, Farkas Levente wrote:
hi, imho it'd be useful to add -mms-bitfields Use native (MS) bitfield layout to the default CFLAGS for mingw. is there objection? of course i we use mingw's gcc for all libs and dll than it's not a problem, but if we use native or precompiled libs or dlls...
There's no obvious downside to using -mms-bitfields, so its reasonable to enable it for all mingw stuff to give us compatability with MS layout.
Daniel
On Wed, Nov 19, 2008 at 12:07:37PM +0000, Daniel P. Berrange wrote:
On Wed, Nov 19, 2008 at 12:45:34PM +0100, Farkas Levente wrote:
hi, imho it'd be useful to add -mms-bitfields Use native (MS) bitfield layout to the default CFLAGS for mingw. is there objection? of course i we use mingw's gcc for all libs and dll than it's not a problem, but if we use native or precompiled libs or dlls...
There's no obvious downside to using -mms-bitfields, so its reasonable to enable it for all mingw stuff to give us compatability with MS layout.
Heh, well there is one downside which is I have to compile everything over again (which takes 12 hours straight, but at least it's now automated :-) Before doing this I'd like to see the full patch to mingw32-filesystem so we can decide what to do & do it in one go...
Rich.
-
Daniel P. Berrange -
Farkas Levente -
Richard W.M. Jones