From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 21:08:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DBCD16A402 for ; Sun, 15 Jul 2007 21:08:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id CA1D913C461 for ; Sun, 15 Jul 2007 21:08:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5EEBE1CCE9; Sun, 15 Jul 2007 23:06:10 +0200 (CEST) Date: Sun, 15 Jul 2007 23:06:10 +0200 From: Ed Schouten To: Michiel Boland Message-ID: <20070715210610.GA39075@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 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: Sun, 15 Jul 2007 21:08:09 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michiel Boland wrote: > It looks like gcc mis-compiles /usr/src/crypto/openssh/monitor_fdpass.c o= n=20 > sparc64. For some reason it optimizes away the assignment of fd on line= =20 > 132: > > fd =3D (*(int *)CMSG_DATA(cmsg)); > > So I guess that every call to mm_receive_fd will return an undefined valu= e. > > If I add -O0 to CFLAGS in /usr/src/secure/lib/libssh/Makefile, ssh with= =20 > UsePrivilegeSeparation=3Dyes works again. > > So, obviously a gcc bug. I will try to generate a smaller test-case for= =20 > this. I've attached an email from Steve Kargl, which is about similar breakage in msun some months ago, right after the gcc 4.2 import: ----- Forwarded message from Steve Kargl = ----- > Date: Sun, 27 May 2007 12:39:29 -0700 > From: Steve Kargl > To: Kris Kennaway > Cc: freebsd-current@freebsd.org, Ed Schouten , > Stefan Ehmann > Subject: Re: HEADS-UP: gcc-4.2 import appears to miscompile libm. >=20 > On Sun, May 27, 2007 at 03:28:25PM -0400, Kris Kennaway wrote: > > On Sun, May 27, 2007 at 08:18:40AM -0700, Steve Kargl wrote: > >> On Sun, May 27, 2007 at 10:53:09AM +0200, Stefan Ehmann wrote: > >>> On Sunday 27 May 2007 01:31:16 Steve Kargl wrote: > >>>> On Sat, May 26, 2007 at 07:09:16PM -0400, Wes Morgan wrote: > >>>>> Working from -O towards -O2 based on the info pages, I can "reprodu= ce" > >>>>> the problem with "-O -fstrict-aliasing -fgcse"... However, -O2 with > >>>>> -fno-strict-aliasing by itself seems to work around the issue. At f= irst > >>>>> glance it looks like a possible interaction between several > >>>>> optimizations. > >>>> > >>>> Ths patch fixes the problem. > >>>> > >>>> --- s_frexpf.c.orig Sat May 26 16:26:50 2007 > >>>> +++ s_frexpf.c Sat May 26 16:28:03 2007 > >>>> @@ -39,6 +39,9 @@ > >>>> } > >>>> *eptr +=3D (ix>>23)-126; > >>>> hx =3D (hx&0x807fffff)|0x3f000000; > >>>> +#if 0 > >>>> *(int*)&x =3D hx; > >>>> +#endif > >>>> + SET_FLOAT_WORD(x,hx); > >>>> return x; > >>>> } > >>>=20 > >>> -fno-strict-aliasing is used by default for me (i386). Also, if you u= se -Wall=20 > >>> the compiler outputs a warning. > >>=20 > >> You apparently don't have CFLAGS set in /etc/make.conf. > >>=20 > >>> [root@something /usr/src/lib/msun/src]# cc -O2 -Wall -pipe -c s_frex= pf.c > >>> s_frexpf.c: In function 'frexpf': > >>> s_frexpf.c:42: warning: dereferencing type-punned pointer will break= =20 > >>> strict-aliasing rules > >>=20 > >> Yes, I know. > >>=20 > >> OTOH, the above patch actually fixes the problem, and libm can then > >> be compiled without -fno-strict-aliasing. > >=20 > > OK, so just to confirm, it's not a miscompilation as originally > > suggested, but a code bug? > >=20 >=20 > Yes, it is a code bug. It is my understanding that C (C99?)=20 > considers "*(int*)&x =3D hx;" to be undefined behavior. From > what I've gleaned from the gcc IRC channel, gcc-4.2 now does > a "load and store" instead of a "store and load" (or vice versa). >=20 > Of course, the patch touches libm so be prepared to be brucified. >=20 > --=20 > Steve >=20 ----- End forwarded message ----- I'm not sure whether it is related at all; it looks quite similar, because of the pointer casting + dereferencing. --=20 Ed Schouten WWW: http://g-rave.nl/ --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGmoxC52SDGA2eCwURAqRAAJ9mn8C4T5u0FPtCfLTRg7AuKUZ2WACeMyF2 MiDkXwkgR2mAe5D1aKIIBig= =M/pj -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--