MinGW: __attribute__((packed)) und alignment

[Walter T. (nicolas)]

Hallo zusammen,

ich habe ein struct definiert mit:

__extension__ typedef struct 
{
    uint16_t val0: 10; 
    uint16_t val1: 10;
    uint8_t crc : 4; 
} __attribute__((packed)) Eedata_t;

und baue das Ganze unter MinGW64 (eine GCC-Ausprägung für Windows). 
Sizeof von Eedata_t liefert 5 - d.h. der Compiler mag das struct nicht 
packen, sondern richtet es an 16-Bit-Grenzen aus.

Gibt es eine Möglichkeit, dem Compiler beizubiegen, ohne Rücksicht auf 
Optimierungsverluste und nötigen Schiebeoperationen das Ganze auf 24 Bit 
zu packen oder muß ich in den sauren Apfel beißen und von Hand schieben?


Viele Grüße
W.T.

[Jörg W. (dl8dtl) (Moderator)]

Seltsam:

$ cat foo.c
#include <stdint.h>

__extension__ typedef struct 
{
    uint16_t val0: 10; 
    uint16_t val1: 10;
    uint8_t crc : 4; 
} __attribute__((packed)) Eedata_t;

Eedata_t foo;

int getval1(Eedata_t *p)
{
   return p->val1;
}
$ cc -O -S foo.c
$ cat foo.s
        .file   "foo.c"
        .text
        .globl  getval1
        .type   getval1, @function
getval1:
.LFB0:
        .cfi_startproc
        movzbl  1(%rdi), %edx
        shrb    $2, %dl
        movzbl  %dl, %edx
        movzbl  2(%rdi), %eax
        andl    $15, %eax
        salq    $6, %rax
        orl     %edx, %eax
        ret
        .cfi_endproc
.LFE0:
        .size   getval1, .-getval1
        .comm   foo,3,1
        .ident  "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4"
        .section        .note.GNU-stack,"",@progbits

Kann mir nicht vorstellen, dass sich ein MinGW32 anders verhält als
der Compiler hier unter Linux.

[Walter T. (nicolas)]

Jörg W. schrieb:
> Kann mir nicht vorstellen, dass sich ein MinGW32 anders verhält als
> der Compiler hier unter Linux.

Schwer zu sagen: Ich nutze und Windows MinGW64 und unter Linux Clang64. 
Aber ich baue mal ein funktionierendes Minimalbeispiel.

[Jörg W. (dl8dtl) (Moderator)]

Mit Clang auf FreeBSD war der generierte Code etwas umständlicher,
aber dennoch klar und deutlich gepackt auf 3 Bytes.

Wie sieht denn obiges Minimalbeispiel mit gleichen Compileroptionen
bei dir unter MinGW64 aus?

[Walter T. (nicolas)]

OK, wir haben uns etwas gedoppelt:

Unter Clang habe ich auch 3 Bytes als Größe (sowohl bei Deinem als auch 
meinem Minimalbeispiel).

Bei Deinem Minimalbeispiel unter MinGW64:

  .file  "foo.c"
  .text
  .globl  getval1
  .def  getval1;  .scl  2;  .type  32;  .endef
  .seh_proc  getval1
getval1:
  .seh_endprologue
  movzbl  2(%rcx), %edx
  movzbl  3(%rcx), %eax
  andl  $3, %eax
  salq  $8, %rax
  orl  %edx, %eax
  ret
  .seh_endproc
  .comm  foo, 5, 0
  .ident  "GCC: (tdm64-1) 5.1.0"

Für mich ist X64/X86er-Asm kryptisch, aber auf den ersten Blick sieht 
das nach einem anderen Offset aus.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> Für mich ist X64/X86er-Asm kryptisch, aber auf den ersten Blick sieht
> das nach einem anderen Offset aus.

Ja, insbesondere hast du da "comm foo, 5, 0" stehen, also 5 Bytes.

Sehr seltsam.  OK, ist natürlich ein GCC 5.x, habe ich hier gerade
nicht zur Hand.

[Johann L. (gjlayde)]

uint16_t etc. als Basis-Typ für Bitfeld ist ja implementation defined 
bzw. deren Unterstützung ist noch nicht einmal vom Standard 
vorgeschrieben.  Gibt es mit unsigned das gleiche Ergebnis?  Und was 
passiert mit aligned(1)?

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Gibt es mit unsigned das gleiche Ergebnis?

Bzw. unsigned char / unsigned short?

[Walter T. (nicolas)]

Jörg W. schrieb:
> Johann L. schrieb:
>> Gibt es mit unsigned das gleiche Ergebnis?
>
> Bzw. unsigned char / unsigned short?

"unsigned" bringt noch eine neue Variante ins Spiel:

  .file  "foo.c"
  .text
  .globl  getval1
  .def  getval1;  .scl  2;  .type  32;  .endef
  .seh_proc  getval1
getval1:
  .seh_endprologue
  movzbl  1(%rcx), %eax
  shrb  $2, %al
  movzbl  %al, %edx
  movzbl  2(%rcx), %eax
  andl  $15, %eax
  salq  $6, %rax
  orl  %edx, %eax
  ret
  .seh_endproc
  .comm  foo, 4, 0
  .ident  "GCC: (tdm64-1) 5.1.0"

bzw. der "sizeof"-Operator liefert 4 zurück.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> der "sizeof"-Operator liefert 4 zurück.

Ja, sagt ja auch die .comm-Anweisung.

[Walter T. (nicolas)]

Ich hab's produktiv mit Bitschieberei gelöst - auch wenn mir type 
punning über Bitfelder lieber ist (da wartbarer).

Es verbleibt also nur die Neugier, warum GCC 5.1.0 und Clang 
unterschiedlicher Meinung sind, was ihre Interpretation von "packed" 
angeht.

(Ich bitte von Vorschlägen à la "nimm eine andere GCC-Version" 
abzusehen. Diese Distribution mit MinGW64/TDM-GCC arbeitet hervorragend 
als MEX-Compiler mit Matlab zusammen - was andere Versionen leider 
(noch) nicht tun.)

[Adib (Gast)]

Hallo zusammen,

das Problem kenne ich. Es gab da mal irgendwo ein Hinweis.

Man muss bei dem MinGW Compiler noch folgende Option setzen:

-mno-ms-bitfields

Grüße,

Adib.
--

[Walter T. (nicolas)]

Adib schrieb:
> Man muss bei dem MinGW Compiler noch folgende Option
> setzen:-mno-ms-bitfields

Danke für den Hinweis!

Mit der obengenannten Compileroption bzw. dem Attribut

__attribute__((gcc_struct))

kommt das erwartete gepackte struct mit 3 Bytes Breite heraus.

Jetzt kann ich meinen Quelltext wieder Zurück-Ändern.