Re: [ECOS] network buffer alignment

[Lars Poeschel <larsi at wh2 dot tu-dresden dot de>]

Am 19.09.2008 um 19:19 schrieb Andrew Lunn:
> This sounds like a toolchain issue.
>
> [Goes away and googles]
>
> http://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html
>
> -malign-int
> -mno-align-int
>    Control whether GCC aligns int, long, long long, float, double,
>    and long double variables on a 32-bit boundary (-malign-int) or a
>    16-bit boundary (-mno-align-int). Aligning variables on 32-bit
>    boundaries produces code that runs somewhat faster on processors
>    with 32-bit busses at the expense of more memory.
>
>    Warning: if you use the -malign-int switch, GCC will align
>    structures containing the above types differently than most
>    published application binary interface specifications for the
>    m68k.
>
> Does this help?

Thanks Andrew, but no, it didn't.
I was not aware of that, but I already use -malign-int as as a global  
build option and I double verified that the enet.c is compiled with  
this option. It is!
The -malign-int gcc documentation sounds to me that only int, long and  
so on are affected but the destination member of the eth_header_t is  
based on an unsigned char array.
The problem is a bit more difficult. It was not sufficient to write  
the __attribute__((aligned(4))) to the declaration of the variable in  
__enet_send or to the definition of the eth_header_t type in net.h. I  
had to write is next to the first member (destination) of the  
eth_header_t to get the alignment as desired. I wondered if this could  
a mistake by gcc, but gcc is right! This is because eth_hdr is a stack  
variable and therefore aligned to its end. Its size is 14 bytes and so  
the beginning is obiviously not on a 4 byte boundary.
As I now know, not all ethernet controllers require a 4 byte aligned  
buffer. So explicitly writing the alignment in the redboot source  
would not be a very good choice. I would propose an architecture  
dependent define that is empty on architectures that don't require the  
alignment and that expands to __attribute__((aligned(4))) on  
architectures that require this. Is this acceptable ?

Lars

Attachment: PGP.sig
Description: This is a digitally signed message part