[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] [PATCH] fix warning for gcc and possible unaligned acce

From: Timmy Brolin
Subject: Re: [lwip-users] [PATCH] fix warning for gcc and possible unaligned access
Date: Wed, 26 Apr 2006 08:03:35 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Pedro Alves wrote:

Timmy Brolin wrote:

Reading through the mailing list archive from two years ago refreshed my memory a bit. For the Texas DSP+compiler the problem was that it do not support packed structs. Several people had the same or similar problems related to unaligned fields in the structs.

The 04/27/04 fix of bug #8708 solves all this by doing two things:
A 2 byte pad is added at the very beginning of the packet. This makes all the header fields problerly aligned, with one exception: The IP fields in the ARP header. This is why ip_addr2 is there. By splitting the 32bit ip_addr into two 16bit fields all fields are properly aligned so that the packed struct attribute is no longer required for most compilers.
This solved the problem for everyone back then.
The 2 byte pad should actually improve performance a bit as well since it makes all the IP and TCP headers nice and aligned.

I have to agree with you that the code must be fixed to comply with C standards. I guess memcpy is fine. But replacing ip_addr2 with ip_addr will break things on all compilers that do not support packed structs. Possibly others as well.

If your compiler generates special code to handle potential alignment problems whenever packed structs are used even if there are no alignment issues, then I suggest you try disabling packed structs. lwip in its current state should compile fine on most compilers even without packed structs.

I went through the archives and read that discussion. I have better understanding of struct ip_addr2 now. Thanks for the pointer. I say, go with memcpy then, and be done with it. The type punning was my original concern. If struct ip_addr2 is kept, is there still a reason to have struct ip_addr packed for compilers that do support packing?

Well, there was a long discussion about that two years ago. According to C standards adatatype may not have alignment requirements larger than its natural alignment, and padding may be introduced into structs to algin the fields in the struct. This would suggest that as long as we design the structs to be perfectly aligned, no compiler will add extra padding. However, some ARM compilers (gcc arm is one of them) apears to align structs to a 32bit boundary, even if it does not contain any 32bit fields. So at least for some ARM compilers you may need packed structs for the ethernet header and the arp header.
The IP and TCP headers should be fine without packing even on ARM.

Timmy Brolin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]