Date: Mon, 13 Nov 2006 15:41:37 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: Joseph Koshy <jkoshy@freebsd.org>, Stefan Farfeleder <stefanf@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/include ar.h Message-ID: <20061113124137.GE25008@rambler-co.ru> In-Reply-To: <20061113220031.V76443@delplex.bde.org> References: <200611130428.kAD4ST0U093715@repoman.freebsd.org> <20061113173927.Q75708@delplex.bde.org> <20061113094311.GC97460@wombat.fafoe.narf.at> <20061113220031.V76443@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--eqp4TxRxnD4KrmFZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 13, 2006 at 10:19:29PM +1100, Bruce Evans wrote:
> On Mon, 13 Nov 2006, Stefan Farfeleder wrote:
[...]
> >You seem to have missed the discussion on -current. GCC pads "struct foo
> >{ char c; };" to 4 bytes on ARM. I agree on __packed not being
> >portable.
>=20
> I don't read -current. Peharps I shouldn't comment on it.
>=20
> I think it is a bug for ARM to do that. If __packed actually gives a size
> of 1, then the padding must be only an optimization for time.
>=20
I thought so as well. Please see this email and emails surrounding it:
http://lists.freebsd.org/pipermail/freebsd-arm/2006-November/000198.html
> struct ar's natural size is 60, so __packed is unnecessary for ARM too
> (unless there is internal padding which would cause more problems).
>=20
Adding __packed didn't change sizeof(struct ar) on FreeBSD/arm but removed
the 4-byte alignment requirement for it, which is what we were attacking.
It now generates less optimal assembly (byte loads instead of 32-bit word
loads), but a discussion on -arm suggested that it's ok for this struct
to be packed.
ISO C99 is clear that padding (except at the beginning) is compiler/machine
dependent:
: Within a structure object, the non-bit-field members and the units
: in which bit-fields reside have addresses that increase in the order
: in which they are declared. A pointer to a structure object, suitably
: converted, points to its initial member (or if that member is a
: bit-field, then to the unit in which it resides), and vice versa.
: There may be unnamed padding within a structure object, but not at
: its beginning.
So there doesn't seem to be a portable way to "lay" structures on
externally supplied data, e.g., data read from files. It means that
we'd have to use bytestrings loads that Poul-Henning mentioned to be
portable, but I think a common sense should win between imaginary
portability and practical performance -- it's often not desirable to
copy a data again, fully or in part, just for the sake of portability
(e.g. in network code) if we know how our beloved compiler packs the
data. And if we ever switch to a compiler with different packing rules
(packing rules in GCC seems to be "natural" in your speak), a LOT of
our programs will break. Again, we added __packed here only for its
(documented) side effect to lower the alignment requirement, not
packing.
In practice, adding __packed on this structure (which is "all chars")
and is already "naturally packed", doesn't have any effect on
assembly on all platforms that don't REQUIRE an unnatural alignment
(i.e., anything except ARM). And by using bytestring loading instead
we'd loose performance on all architectures. This OTOH penalizes
code on ARM, but I think that IN THIS PARTICULAR CASE of a structure
of all chars it's okay.
I agree that -Wpacked should probably be used to identify harmful
instances of __packed.
Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
--eqp4TxRxnD4KrmFZ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFWGgBqRfpzJluFF4RAg7EAJ0SR2pyKQT2dWRqj/rgBAv/HvqZdwCfestn
zQ6psjV1SD7uf6io6xqp0XU=
=zqXy
-----END PGP SIGNATURE-----
--eqp4TxRxnD4KrmFZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061113124137.GE25008>