From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 08:19:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DD3106566C; Tue, 1 Feb 2011 08:19:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDC58FC0C; Tue, 1 Feb 2011 08:19:04 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E9D0D45CA0; Tue, 1 Feb 2011 09:19:02 +0100 (CET) Received: from localhost (58.wheelsystems.com [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8C6A045C8A; Tue, 1 Feb 2011 09:18:56 +0100 (CET) Date: Tue, 1 Feb 2011 09:18:44 +0100 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20110201081844.GA1897@garage.freebsd.pl> References: <201101312256.p0VMuI6F075840@freebsd-current.sentex.ca> <20110131235153.GC1746@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: ia64@freebsd.org, marcel@FreeBSD.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 08:19:05 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2011 at 04:56:06PM -0800, Marcel Moolenaar wrote: >=20 > On Jan 31, 2011, at 3:51 PM, Pawel Jakub Dawidek wrote: >=20 > > On Mon, Jan 31, 2011 at 10:56:18PM +0000, FreeBSD Tinderbox wrote: > > [...] > >> cc -O2 -pipe -I/src/sbin/hastctl/../hastd -DINET -DINET6 -DYY_NO_UNPU= T -DYY_NO_INPUT -DHAVE_CRYPTO -std=3Dgnu99 -Wsystem-headers -Werror -Wall -= Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -W= shadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-= externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/= sbin/hastctl/../hastd/proto_common.c > >> cc1: warnings being treated as errors > >> /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_d= escriptor_send': > >> /src/sbin/hastctl/../hastd/proto_common.c:116: warning: cast increases= required alignment of target type > >> /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_d= escriptor_recv': > >> /src/sbin/hastctl/../hastd/proto_common.c:146: warning: cast increases= required alignment of target type > >> /src/sbin/hastctl/../hastd/proto_common.c:149: warning: cast increases= required alignment of target type > >> *** Error code 1 > >=20 > > Marcel, do you have an idea how one can use CMSG_NXTHDR() on ia64 with > > high WARNS? With WARNS=3D6 I get those errors and I've no idea how to f= ix > > it properly. If there is a fix, CMSG_NXTHDR() should probably be fixed, > > but maybe I'm wrong? >=20 > this warning indicates that you're casting from a pointer to type P > (P having alignment constraints Ap) to a pointer to type Q (Q having > alignment constraints Aq), and Aq > Ap. The compiler tells you that > you may end up with misaligned accesses. >=20 > If you know that the pointer satisfies Aq, you can cast through (void *) > to silence the compiler. If you cannot guarantee that, you have a bigger > problem. Solutions include "packing" type Q to reduce Aq or to copy the > data to a local variable. >=20 > Take the statement at line 116 for example: > *((int *)CMSG_DATA(cmsg)) =3D fd; >=20 > We're effectively casting from a (char *) to a (int *) and then doing > a 32-bit access (write). The easy fix (casting through (void *) is not > possible, because you cannot guarantee that the address is properly > aligned. cmsg points to memory set aside by the following local > variable: > unsigned char ctrl[CMSG_SPACE(sizeof(fd))]; >=20 > There's no guarantee that the compiler will align the character array > at a 32-bit boundary (though in practice it seems to be). I have seen > this kind of construct fail on ARM and PowerPC for example. >=20 > In any case: The safest approach here is to use le32enc or be32enc > rather than casting through (void *). Obviously these function encode > using a fixed byte order when the original code is using the native > byte order of the CPU. Having native encoding functions help. >=20 > You could use bcopy as well, but the compiler is typically too smart > for its own good and it will try to optimize the call away. This > leaves you with the same misaligned access that you tried to avooid > by using bcopy(). You need to trick the compiler so that it won't > optimize the bcopy away, like: > bcopy((void *)&fd, CMSG_DATA(cmsg), sizeof(fd)); Interesting. I did use bcopy() to silence the warning, but the need to cast to (void *) is surprising. Still, I'm more concerned with CMSG_NXTHDR() macro, which from what I see might not be fixed by casting arguments. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk1HweQACgkQForvXbEpPzQe3wCeJ8nssh1lMJ59WFbgVgdor5Nq LEwAmwXQN+km5rNmCtNwQSOJduXxuyl2 =TMUG -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--