跨字边界的MinGW64位字段访问是错误的。

Question

我正在研究不同的编译器如何处理结构位字段成员以及跨越基元类型边界的成员的非对齐访问，我认为MinGW64被窃听了。我的测试程序是：

#include <stdint.h>
#include <stdio.h>

/* Structure for testing element access

The crux is the ISO C99 6.7.2.1p10 item:

An implementation may allocate any addressable storage unit large enough to hold a bitfield.
If enough space remains, a bit-field that immediately follows another bit-field in a
structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
implementation-defined. The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined. The alignment of the
addressable storage unit is unspecified.
*/

typedef struct _my_struct
{
    /* word 0 */
    uint32_t    first           :32;    /**< A whole word element   */
    /* word 1 */
    uint32_t    second          :8;     /**< bits 7-0               */
    uint32_t    third           :8;     /**< bits 15-8              */
    uint32_t    fourth          :8;     /**< bits 23-16             */
    uint32_t    fifth           :8;     /**< bits 31-24             */
    /* word 2 */
    uint32_t    sixth           :16;    /**< bits 15-0              */
    uint32_t    seventh         :16;    /**< bits 31-16             */
    /* word 3 */
    uint32_t    eigth           :24;    /**< bits 23-0              */
    uint32_t    ninth           :8;     /**< bits 31-24             */
    /* word 4 */
    uint32_t    tenth           :8;     /**< bits 7-0               */
    uint32_t    eleventh        :24;    /**< bits 31-8              */
    /* word 5 */
    uint32_t    twelfth         :8;     /**< bits 7-0               */
    uint32_t    thirteeneth     :16;    /**< bits 23-8              */
    uint32_t    fourteenth      :8;     /**< bits 31-24             */
    /* words 6 & 7 */
    uint32_t    fifteenth       :16;    /**< bits 15-0              */
    uint32_t    sixteenth       :8;     /**< bits 23-16             */
    uint32_t    seventeenth     :16;    /**< bits 31-24 & 7-0       */
    /* word 7 */
    uint32_t    eighteenth      :24;    /**< bits 31-8              */
    /* word 8 */
    uint32_t    nineteenth      :32;    /**< bits 31-0              */
    /* words 9 & 10 */
    uint32_t    twentieth       :16;    /**< bits 15-0              */
    uint32_t    twenty_first    :32;    /**< bits 31-16 & 15-0      */
    uint32_t    twenty_second   :16;    /**< bits 31-16             */
    /* word 11 */
    uint32_t    twenty_third    :32;    /**< bits 31-0              */
} __attribute__((packed)) my_struct;


uint32_t buf[] = {
        0x11223344, 0x55667788, 0x99AABBCC, 0x01020304, /* words 0  - 3     */
        0x05060708, 0x090A0B0C, 0x0D0E0F10, 0x12131415, /* words 4  - 7     */
        0x16171819, 0x20212324, 0x25262728, 0x29303132, /* words 8  - 11    */
        0x34353637, 0x35363738, 0x39404142, 0x43454647  /* words 12 - 15    */
};

uint32_t data[64];

int main(void)
{
    my_struct *p;

    p = (my_struct*) buf;

    data[0] = 0;
    data[1] = p->first;
    data[2] = p->second;
    data[3] = p->third;
    data[4] = p->fourth;
    data[5] = p->fifth;
    data[6] = p->sixth;
    data[7] = p->seventh;
    data[8] = p->eigth;
    data[9] = p->ninth;
    data[10] = p->tenth;
    data[11] = p->eleventh;
    data[12] = p->twelfth;
    data[13] = p->thirteeneth;
    data[14] = p->fourteenth;
    data[15] = p->fifteenth;
    data[16] = p->sixteenth;
    data[17] = p->seventeenth;
    data[18] = p->eighteenth;
    data[19] = p->nineteenth;
    data[20] = p->twentieth;
    data[21] = p->twenty_first;
    data[22] = p->twenty_second;
    data[23] = p->twenty_third;

    if( p->fifth == 0x55 )
    {
        data[0] = 0xCAFECAFE;
    }
    else
    {
        data[0] = 0xDEADBEEF;
    }

    int i;
    for (i = 0; i < 24; ++i) {
        printf("data[%d] = 0x%0x\n", i, data[i]);
    }
    return data[0];
}

我发现的结果是：

| Data Member | Type    | GCC Cortex M3  | GCC mingw64   | GCC Linux     | GCC Cygwin    |
|:------------|:-------:|:---------------|:--------------|:--------------|:--------------|
| data[0]     | uint32_t| 0x0            | 0xcafecafe    | 0xcafecafe    | 0xcafecafe    |
| data[1]     | uint32_t| 0x11223344     | 0x11223344    | 0x11223344    | 0x11223344    |
| data[2]     | uint32_t| 0x88           | 0x88          | 0x88          | 0x88          |
| data[3]     | uint32_t| 0x77           | 0x77          | 0x77          | 0x77          |
| data[4]     | uint32_t| 0x66           | 0x66          | 0x66          | 0x66          |
| data[5]     | uint32_t| 0x55           | 0x55          | 0x55          | 0x55          |
| data[6]     | uint32_t| 0xbbcc         | 0xbbcc        | 0xbbcc        | 0xbbcc        |
| data[7]     | uint32_t| 0x99aa         | 0x99aa        | 0x99aa        | 0x99aa        |
| data[8]     | uint32_t| 0x20304        | 0x20304       | 0x20304       | 0x20304       |
| data[9]     | uint32_t| 0x1            | 0x1           | 0x1           | 0x1           |
| data[10]    | uint32_t| 0x8            | 0x8           | 0x8           | 0x8           |
| data[11]    | uint32_t| 0x50607        | 0x50607       | 0x50607       | 0x50607       |
| data[12]    | uint32_t| 0xc            | 0xc           | 0xc           | 0xc           |
| data[13]    | uint32_t| 0xa0b          | 0xa0b         | 0xa0b         | 0xa0b         |
| data[14]    | uint32_t| 0x9            | 0x9           | 0x9           | 0x9           |
| data[15]    | uint32_t| 0xf10          | 0xf10         | 0xf10         | 0xf10         |
| data[16]    | uint32_t| 0xe            | 0xe           | 0xe           | 0xe           |
| data[17]    | uint32_t| 0x150d         | 0x1415        | 0x150d        | 0x150d        |
| data[18]    | uint32_t| 0x121314       | 0x171819      | 0x121314      | 0x121314      |
| data[19]    | uint32_t| 0x16171819     | 0x20212324    | 0x16171819    | 0x16171819    |
| data[20]    | uint32_t| 0x2324         | 0x2728        | 0x2324        | 0x2324        |
| data[21]    | uint32_t| 0x27282021     | 0x29303132    | 0x27282021    | 0x27282021    |
| data[22]    | uint32_t| 0x2526         | 0x3637        | 0x2526        | 0x2526        |
| data[23]    | uint32_t| 0x29303132     | 0x35363738    | 0x29303132    | 0x29303132    |

GCC Cortex M3 is
arm-none-eabi-gcc (GNU MCU Eclipse ARM Embedded GCC, 32-bit) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]

GCC Mingw is
gcc.exe (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 8.1.0

GCC Linux is
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)

GCC Cygwin is
gcc (GCC) 7.4.0

所有GCC版本似乎都正确地处理了未对齐访问(如my_struct.thirteeneth)。

问题并不是跨越单词边界(my_struct.seventeenth)的成员是不同的，因为上面引用的C99标准清楚地指出，行为是由实现定义的。问题是，所有后续访问都显然是不正确的 (data17和on)，甚至对于对齐的成员(my_struct.nineteenth & my_struct.twenty_third)也是如此。这里发生了什么，这是一个错误，还是这些有效值？

Answer 1

它没有被窃听，它根据windows ABI设置位域。

根据gcc博士

如果在结构上使用打包，或者使用位字段，那么Microsoft的结构布局可能与GCC通常所做的不同。

用mingw64编译-mno-ms-bitfields版本来修正差异。或者用-mms-bitfields编译所有其他版本，以将结构布局得与mingw相同。

Answer 2

像GCC这样被广泛使用的编译器有错误的可能性不是零，而是非常小。很有可能是PEBKAS。;-)

无论如何，我已经用"gcc (x86_64-posix-seh-rev0，由MinGW-W64项目构建) 8.1.0“编译了您的程序，并得到了与您在专栏"mingw64”中相同的结果。

更精细的外观显示，编译器在32位边界上对齐位字段，这恰好是int的宽度。这完全符合标准C17第6.7.2.1章的规定，该章规定，“跨界”(用附件J.3.9的话说)是执行定义的。

其他GCC变体不对位场和支持跨越32位边界.

它显然不是一个bug，它的值是有效的。它可能值得研究原因，也许可以发布一个特性请求。

编辑：

为了澄清，这是布局与对齐。seventeenth元素没有什么问题，如下所示：

/* 0x11223344: word 0 */
uint32_t    first           :32;
/* 0x55667788: word 1 */
uint32_t    second          :8;
uint32_t    third           :8;
uint32_t    fourth          :8;
uint32_t    fifth           :8;
/* 0x99AABBCC: word 2 */
uint32_t    sixth           :16;
uint32_t    seventh         :16;
/* 0x01020304: word 3 */
uint32_t    eigth           :24;
uint32_t    ninth           :8;
/* 0x05060708: word 4 */
uint32_t    tenth           :8;
uint32_t    eleventh        :24;
/* 0x090A0B0C: word 5 */
uint32_t    twelfth         :8;
uint32_t    thirteeneth     :16;
uint32_t    fourteenth      :8;
/* 0x0D0E0F10: words 6 */
uint32_t    fifteenth       :16;
uint32_t    sixteenth       :8;
/* 0x12131415: word 7, because "seventeenth" does not fit in the space left */
uint32_t    seventeenth     :16;
/* 0x16171819: word 8, because "eighteenth" does not fit in the space left */
uint32_t    eighteenth      :24;
/* 0x20212324: word 9, because "nineteenth" does not fit in the space left */
uint32_t    nineteenth      :32;
/* 0x25262728: words 10 */
uint32_t    twentieth       :16;
/* 0x29303132: word 11, because "twenty_first" does not fit in the space left */
uint32_t    twenty_first    :32;
/* 0x34353637: word 12 */
uint32_t    twenty_second   :16;
/* 0x35363738: word 13, because "twenty_third" does not fit in the space left */
uint32_t    twenty_third    :32;

Answer 3

在任何情况下，您都不能完全依赖()，它依赖于位字段在结构中的排列方式。

Per ，C11标准第11段 (黑石矿)：

实现可以分配任何足够大的可寻址存储单元，以容纳位字段。如果有足够的空间，在结构中立即跟随另一个位场的位场应被包装成同一单元的相邻位元。如果空间不足，则将不适合的位字段放入下一个单元或重叠相邻单元是实现定义的。单元内位字段的分配顺序(高阶到低阶或低阶到高阶)是实现定义的。可寻址存储单元的对齐未指定。

你甚至引用了这个。因此，实现没有“不正确”的方法来布局一个位字段。

因此，您不能依赖位字段容器的大小。

你不能依赖于是否有一个位场交叉单位.

不能依赖单元内位字段的顺序.

然而，您的问题假设您可以做到所有这些，即使使用“正确”等术语，当您看到您所期望的和“明显不正确”来描述位字段布局时，您并没有预料到。

这并不是“明显不正确”。

如果您需要知道位在结构中的位置，那么您就无法移植地使用位字段。

事实上，您在这个问题上的所有努力都是一个完美的案例，研究了为什么不能依赖位字段。