From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 00:56:24 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 359A71065695; Tue, 1 Feb 2011 00:56:24 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 1685E8FC12; Tue, 1 Feb 2011 00:56:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common2-26.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp025.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LFW00JP9YLINI40@asmtp025.mac.com>; Mon, 31 Jan 2011 16:56:09 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-31_10:2011-01-31, 2011-01-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1101310186 From: Marcel Moolenaar In-reply-to: <20110131235153.GC1746@garage.freebsd.pl> Date: Mon, 31 Jan 2011 16:56:06 -0800 Message-id: References: <201101312256.p0VMuI6F075840@freebsd-current.sentex.ca> <20110131235153.GC1746@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1082) 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 00:56:24 -0000 On Jan 31, 2011, at 3:51 PM, Pawel Jakub Dawidek wrote: > 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_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -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_descriptor_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_descriptor_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 > > Marcel, do you have an idea how one can use CMSG_NXTHDR() on ia64 with > high WARNS? With WARNS=6 I get those errors and I've no idea how to fix > it properly. If there is a fix, CMSG_NXTHDR() should probably be fixed, > but maybe I'm wrong? 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. 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. Take the statement at line 116 for example: *((int *)CMSG_DATA(cmsg)) = fd; 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))]; 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. 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. 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)); HTH, -- Marcel Moolenaar xcllnt@mac.com