On Mon, May 15, 2006 at 11:10:09PM -0400, der Mouse wrote:
> > 	struct bootpcontext {
> [...]
> > 		struct in_addr dhcp_serverip; 
> 
> > 	struct in_addr {
> > 		uint32_t s_addr;
> > 	} __attribute__((__packed__));
> 
> > [bcopy to such a bootpcontext's dhcp_serverip generates:]
> 
> >         lwl     $2,3($4)
> >         lwr     $2,0($4)
> >         sw      $2,22($17)
> 
> > where sw is an aligned store, which promptly panics when it tries to
> > store at an unaligned address.
> 
> > Is gcc4 doing something wrong here,
> 
> Sounds like it to me.  It's obeying the packed attribute in that it's
> putting the struct at an unaligned address, but then forgetting about
> it when it comes time to generate code.

At least something 'not useful' (at that will break elsewhere) since the 
definition of  __attribute__((__packed__)) is implementation specific.

packing a structure (in gcc3) has two effects:
1) removing padding bytes between structure elements
2) allowing the structure itself by be on a misaligned address
   (This absolutely has to be done if trailing padding is removed.)

Now ISTR mention of gcc4 giving an error/warning message about structures
being marked 'packed' when there are no gaps (or is my memory failing?).
If some bright sparc has decided that they don't need to use misalgned
accesses for all fields of packed structures - not just ones that aren't
aligned within the structure - then large tracts of existing code will
be broken beyond belief on systems that don't have hardware support for
misaligned access.

Either that or support for 'packed' should be completly deleted and
expunged for the memory of every programmer :-)

	David

-- 
David Laight: david@l8s.co.uk