Date: Sun, 11 May 2003 00:16:12 +0200 From: Maxime Henrion <mux@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Unaligned access fault in fxp on alpha Message-ID: <20030510221612.GT21011@elvis.mu.org> In-Reply-To: <16060.419.751589.275820@grasshopper.cs.duke.edu> References: <20030509163718.GA22231@rot13.obsecurity.org> <16060.419.751589.275820@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > > Kris Kennaway writes: > > I reported this to mux 3 days ago, but haven't heard any > > acknowledgement from him of the issue. Could someone else > > investigate? This is a reproducible panic. > > > > Can you try this patch please? > > It causes gcc to emit slightly different code, which deals with > storing to aligned 16-bit values. > > What's happening is that because the u_int32_t link_addr (and rbd_addr) > fields preceded the "size" field, gcc was assuming that the rfa struct > would be aligned and was cheating. It was using operations which only > work on aligned-32 bit values on 16-bit values. Removing the > u_int32_t's disabuses gcc of this assumption, therby causing safe > code to be emitted. > > I don't understand why mux changed these fields in rev 1.31, with, so > I'm not sure that I want to commit this until mux reviews it. For all > I know, it breaks sparc64 or something.. Thanks Andrew, I should have taken care of this since some time but was veyr busy these days. I removed them because they were just looking bogus. I wanted to ask people to test a patch adding a __packed in the struct definition to see if it fixed things. If it works with a __packed keyword, I'd like it better than going back to having an array of four u_int8_t. Otherwise I'll put the u_int8_t back. Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030510221612.GT21011>