From owner-cvs-all@FreeBSD.ORG Mon Nov 13 12:41:43 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4362316A47B; Mon, 13 Nov 2006 12:41:43 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72BD743D62; Mon, 13 Nov 2006 12:41:34 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id AD1FB5D8F; Mon, 13 Nov 2006 15:41:33 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 8A3D25D89; Mon, 13 Nov 2006 15:41:33 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kADCfbQK029310; Mon, 13 Nov 2006 15:41:38 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 15:41:37 +0300 From: Ruslan Ermilov To: Bruce Evans Message-ID: <20061113124137.GE25008@rambler-co.ru> References: <200611130428.kAD4ST0U093715@repoman.freebsd.org> <20061113173927.Q75708@delplex.bde.org> <20061113094311.GC97460@wombat.fafoe.narf.at> <20061113220031.V76443@delplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline In-Reply-To: <20061113220031.V76443@delplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Joseph Koshy , Stefan Farfeleder , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/include ar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 12:41:43 -0000 --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--