From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Wed, 28 Jan 2009 10:58:11 -0800 Subject: [U-Boot] IP_t should be a "packed" struct In-Reply-To: <4980A5AA.2090306@ge.com> References: <200901271932.11060.luigi.mantellini.ml@gmail.com> <49809C21.6070004@gmail.com> <4980A5AA.2090306@ge.com> Message-ID: <4980AAC3.7020601@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jerry Van Baren wrote: > Ben Warren wrote: >> Luigi 'Comio' Mantellini wrote: >>> Hi ML, >>> >>> I'm working on a mips target and I used qemu_mips target to simulate >>> my target (that I hope to have in the next week...) >>> >>> Following my activities I noticed that IP_t structure is no defined >>> with attribute "packed". I noticed this issue because using a >>> self-made toolchain (gcc4.2.4+binutils2.8+uclibc0.9.30) the compiler >>> has aligned all bytes to 32bit boundary. This is not ok, because the >>> packets IP_t can be non aligned (see the /net/net.c PingSend >>> function, for an example). >>> >>> >> Why is your compiler aligning all bytes to 32-bit boundary? Seems >> like an awful waste of space. This struct should pack itself nicely, >> and does on the small sample of toolchains I've tried (gcc 4.3.2 >> x86_64 and gcc 4.0.0 ppc_4xx). > > The compiler is optimizing for speed and/or execution size at the > expense of larger data structures either by command (e.g. a -O option) > or as part of the compiler writer's choice. CPUs almost always > execute code significantly faster when the data is properly aligned. > Many CPUs require software to deal with the misalignment which costs > code space and execution time. > > Since the compiler wasn't instructed that the IP headers needed to be > packed, it is within the compiler's right to not pack them. > Sure. In this case, though, the optimization's not necessarily going to gain anything since we never use a raw struct IP_t, only pointers that overlay other char arrays through casting. Of course there's no point discussing this much further here, but I suspect that this packing problem will exist in many more places than the protocol headers. > [snip] > > Best regards, > gvb > regards, Ben