Richard W.M. Jones
rjones at redhat.com
Wed Nov 19 11:55:12 UTC 2008
On Wed, Nov 19, 2008 at 12:45:34PM +0100, Farkas Levente wrote:
> 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
5.34.3 i386 Variable Attributes
Two attributes are currently defined for i386 configurations:
`ms_struct' and `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
unsigned long bf_1 : 12;
unsigned long : 0;
unsigned long bf_2 : 12;
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.
char foo : 4;
short : 0;
char foo : 4;
short : 0;
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
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
char foo : 6;
long : 0;
Here, `t4' will take up 4 bytes.
3. Zero-length bitfields following non-bitfield members are
long : 0;
Here, `t5' will take up 2 bytes.
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
More information about the mingw