Skip site navigation (1)Skip section navigation (2)
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>