Jim Klimov wrote:
On 2013-04-26 09:30, Jean-Pierre wrote:
struct io_stack_location {
uint8_t isl_major;
uint8_t isl_minor;
uint8_t isl_flags;
uint8_t isl_ctl;
...
union {
struct {
uint32_t isl_len;
/* "POINTER_ALIGNMENT" according to msdn */
uint32_t *isl_key;
uint64_t isl_byteoff;
} isl_read;
...
Tke key element is the attribute "POINTER_ALIGNMENT" on
the msdn description you copied above. On a 64-bit CPU
this is supposed to mean alignment to a multiple of 8
bytes. The attribute is defined for the field isl_key
(and others), but this recursively implies the outer
structures and union to also be aligned, otherwise the
inner alignment would not hold. Compilers are expected
to care for it.
But in this case you have 4 1-byte values an 1 4-byte value
and then the pointer, doesn't this make the pointer 8-byte
aligned without fillers? (And the isl_len thus starts at
the offset of 4?)
No, because the inner structs have to stand by themselves.
For instance you must be able to define a pointer to the
inner struct "isl_read", and the fields must be aligned
from the pointer.
I spent much time on this issue, and I added the checks
so that other users would not get stuck on it. (snip)
I have had to check them in the binary image of the driver,
so I am pretty sure about them.
Ok, I'll trust your judgement, but my "gut feeling" says
that this may be a source of problems with my compilations...
Or maybe that some other structures need to be validated
similarly.
Probably so. The checks I defined only deal with the
structs I had problems with.
Also, isn't it possible to use some compiler pragma to
enforce proper (er, microsoft-expected) alignment of
these structures' fields?
This is possible, but it would create more compiler
dependencies. I prefer inserting dummy fields with a
condition on a 64-bit architecture.
Jean-Pierre
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
