[oi-dev] Broadcom wireless drivers for OpenIndiana

[Jean-Pierre]

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