At 03:11 PM 11/26/2006, you wrote:
> This sounds really strange! Particularly that uip_conns[1] did not
work as expected. The C compiler *should* align structs in an array
so that they are not > malfunctioning. (Or was this a problem when
structure packing was used?)
Yes, this was the problem when using "-fpack-struct". The compiler is
required to pack array elements, it's the structures that can/should
be padded to maintain alignment. For the case of passing around a
pointer to the struct it's not unreasonable (maybe even required) that
the compiler assume that the target is aligned.
Just to be explicit:
1) [with "-fpack-struct"]: much of the code had difficulty when given
the pointer &uip_conns[1]. (Symptom: crashes)
2) [without "-fpack-struct"]: the ethernet address/header structs
were 8/20 bytes respectively, so uIP had diffficulty
decoding the headers (Symptom: "ip: Invalid version or header length").
3) [+ uip_eth_addr/hdr packed]: Symptom: outgoing packets looked
well-formed, but ACKs from the other end weren't
recognized. Digging through the generated code, all (critical)
lengths/offsets looked right. After about an hour of this
I just forced packing on uip_tcpip_hdr and it started working.
> try to declare the uip_buf as a u32_t instead of an u8_t and read
Ethernet packets into uip_buf[2] and see if that works even
> without packed structures
I tried forcing uip_buf to an odd-halfword offset, and it seems to
work fine without packing uip_tcpip_hdr. (Interesting.
I wonder if the packing inhibits certain strength-reductions like
maybe coalescing two "aligned" halfword references
into a single fullword reference. If the compiler had been doing this
I probably wouldn't have noticed.)
Changing all the uip_buf references looked pretty messy, so I
embedded it in a (32-bit-aligned) struct with a leading
pad halfword, and provided a syntax macro to reference the buffer
proper (ugly, but small (:-))). I'm not sure what is
the simplest solution here.
