[arm-elf-gcc] Über struct auf byte-Array zugreifen.

[Laurenz K. (gimmebottles)]

Hallo,

ich bin gerade an der Portierung von uIP auf einen LPC2387 und stehe vor 
einem Problem.

uIP kopiert empfangene Daten in einem Array uint8_t uip_buf[LEN]. In der 
main-Schleife wird dann folgendermaßen auf dieses Array zugegriffen, um 
die Art des empfangenen Pakets zu bestimmen:

if((uint16_t)BUF->type == htons(UIP_ETHTYPE_IP))

wobei BUF so definiert ist:

#define BUF ((struct uip_eth_hdr *)&uip_buf[0])

Schließlich noch uip_eth_hdr:

struct uip_eth_hdr {
  struct uip_eth_addr dest;
  struct uip_eth_addr src;
  u16_t type;
};

uip_eth_addr sind jeweils 6 uint6_t Werte für die MAC-Adressen.

Wenn im uip_buf folgendes enthalten ist:

0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,
0x08,0x06

Dann gehe ich davon aus, dass BUF->type mir 0x0806 liefert. Das tut es 
aber nicht, BUF->type gibt mir nur 0x08 zurück, das zweite byte wird 
anscheinend nicht gelesen.

Kommt jemand dieses Problem bekannt vor?

Vielen Dank,

Laurenz

[Dr. Sommer (Gast)]

Wenn schon hätte ich 0x0608 erwartet, wegen Little Endian. Verifiziere 
doch mal im Debugger, dass die Adresse von BUF->type an die richtige 
Stelle im Speicher verweist.

[(prx) A. K. (prx)]

Wenn der Ethernet-Frame word-aligned ist, dann sind die IP-Adressen 
misaligned. Man kann dann mit einem ARM7 nicht direkt auf das Wort 
zugreifen. Was ausserdem die falsche Bytereihenfolge hat.

Manche legen den Ethernet-Frame so in den Speicher, dass er passend 
misaligned ist, dafür aber der IP Header word-aligned ist.

In jedem Fall muss für Zugriffe >Byte ein Alignment sichergestellt sein. 
Bei Byte-Arrays ist das von Haus aus nicht gewährleistet.

[(prx) A. K. (prx)]

Dr. Sommer schrieb:
> Wenn schon hätte ich 0x0608 erwartet, wegen Little Endian.

Wird er auch kriegen, wenn richtig gemacht. Weshalb er mit htons(0x0806) 
vergleicht. 08 kriegt er, weil beim ARM7 beim misaligned load zwar immer 
das adressierte Byte in Bits 0..7 vom Register landet, aber der Rest 
nicht stimmt.

[Laurenz K. (gimmebottles)]

Um auf die richtigen Daten (0x0806) zuzugreifen, müsste BUF->type ja auf 
uip_buf + 12 verweisen, er verweißt aber auf uip_buf + 16, wo zufällig 
auch eine 0x08 liegt.

[(prx) A. K. (prx)]

Laurenz K. schrieb:
> Um auf die richtigen Daten (0x0806) zuzugreifen, müsste BUF->type ja auf
> uip_buf + 12 verweisen, er verweißt aber auf uip_buf + 16

Woran erkennst du das? Wenn uip_eth_addr aus 6 uint8_t besteht, dann 
liegt type an 12.

[Laurenz K. (gimmebottles)]

A. K. schrieb:
> Laurenz K. schrieb:
>> Um auf die richtigen Daten (0x0806) zuzugreifen, müsste BUF->type ja auf
>> uip_buf + 12 verweisen, er verweißt aber auf uip_buf + 16
>
> Woran erkennst du das? Wenn uip_eth_addr aus 6 uint8_t besteht, dann
> liegt type an 12.

Wenn ich

test = &BUF->type;

einfüge, sehe ich im Debugger dass test auf uip_buf + 16 verweißt.

[(prx) A. K. (prx)]

Dann stimmt was an uip_eth_addr nicht. Eine struct aus 6 Bytes sollte 
nur 6 Bytes gross sein und keine Alignment-Einschränkungen haben.

[Laurenz K. (gimmebottles)]

A. K. schrieb:
> Dann stimmt was an uip_eth_addr nicht. Eine struct aus 6 Bytes sollte
> nur 6 Bytes gross sein und keine Alignment-Einschränkungen haben.

Ja, ein __attribute__((packed)) wirkt da Wunder :D

Scheint jetzt zu laufen, mal sehen was noch kommt.