Date: Tue, 13 May 2003 15:26:17 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Maxime Henrion <mux@freebsd.org> Cc: current@freebsd.org Subject: Re: Unaligned access fault in fxp on alpha Message-ID: <20030513152535.H81955@gamplex.bde.org> In-Reply-To: <20030511195402.C75054@gamplex.bde.org> References: <20030509163718.GA22231@rot13.obsecurity.org> <20030510221612.GT21011@elvis.mu.org> <20030511195402.C75054@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Resending after bounce] On Sun, 11 May 2003, Maxime Henrion wrote: > 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. __packed looks very bogus to me. It is a syntax error for non-gcc compilers. The code was apparently originally carefully written to not depend on gccisms. I think __packed is also a pessimization here on some arches. The struct also has some u_int16_t's which are aligned, but __packed says that everything may be misaligned (unless you also use __aligned(mumble)). On some arches, the compiler will have to access everything as bytes and reassemble, or more complicated things if byte accesses are impossible. Since the accesses are for machine registers, the accesses with unusual widths and/or alignments for this may even be bugs. I just noticed that gcc now has some warnings -Wpacked and -Wpadded to help detect gratuitous use of __packed and errors in explicit packing/ padding. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030513152535.H81955>