amd64/98893: cc error at -O2 on amd64/6-STABLE compiling port ucspi-tcp

[Kris Kennaway]

The following reply was made to PR amd64/98893; it has been noted by GNATS.

From: Kris Kennaway <kris at obsecurity.org>
To: Andrew Reilly <andrew-freebsd at areilly.bpc-users.org>
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: amd64/98893: cc error at -O2 on amd64/6-STABLE compiling port ucspi-tcp
Date: Mon, 12 Jun 2006 22:27:03 -0400

 --NzB8fVQJ5HfG6fxh
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jun 13, 2006 at 02:01:22AM -0000, Andrew Reilly wrote:
 >=20
 > >Number:         98893
 > >Category:       amd64
 > >Synopsis:       cc error at -O2 on amd64/6-STABLE compiling port ucspi-t=
 cp
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    freebsd-amd64
 > >State:          open
 > >Quarter:       =20
 > >Keywords:      =20
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Tue Jun 13 02:10:18 GMT 2006
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Andrew Reilly
 > >Release:        FreeBSD 6.1-STABLE amd64
 > >Organization:
 > >Environment:
 > System: FreeBSD duncan.reilly.home 6.1-STABLE FreeBSD 6.1-STABLE #4: Mon =
 Jun 12 13:57:57 EST 2006 root@:/usr/obj/usr/src/sys/DUNCAN amd64
 >=20
 > 	machine is an AMD64-X2-4200+
 > 	/etc/make.conf exists but does not set or change CFLAGS
 >=20
 > >Description:
 > 	tcpserver, from the port sysutils/ucspi-tcp, built as
 > 	normal, fails with the error message:=20
 > 	"tcpserver: fatal: temporarily unable to figure out IP
 > 	address for 0.0.0.0: file does not exist"
 > 	Debugging shows that this is the result of the following
 > 	line in dns_rcrw.c always returning -1:
 > 	  if (gethostname(host,sizeof host) =3D=3D -1) return -1;
 > 	Now, ENOFILE ("file does not exist") is not a valid
 > 	errno return from gethostname, and separate testing
 > 	shows that gethostname() runs just fine.  Indeed, this
 > 	piece of kdump output shows that it was called, and
 > 	returned 0, as expected:
 >  13441 tcpserver CALL  open(0x4086fe,0x4,0x40)
 >  13441 tcpserver NAMI  "/etc/resolv.conf"
 >  13441 tcpserver RET   open -1 errno 2 No such file or directory
 >  13441 tcpserver CALL  __sysctl(0x7fffffffe3b8,0x2,0x7fffffffe3d0,0x7ffff=
 fffe3b0,0,0)
 >  13441 tcpserver RET   __sysctl 0
 >  13441 tcpserver CALL  write(0x2,0x50b960,0x5f)
 >  13441 tcpserver GIO   fd 2 wrote 95 bytes
 >        "tcpserver: fatal: temporarily unable to figure out IP address for=
  0.0.\
 >         0.0: file does not exist
 >        "
 >  13441 tcpserver RET   write 95/0x5f
 >  13441 tcpserver CALL  exit(0x6f)
 > 	(gethostname is that __sysctl.  errno is no-doubt still
 > 	set to ENOFILE from the failed open of /etc/resolv.conf.)
 > 	So: the only conclusion is that the compiler flubbed the
 > 	comparison of the return value against -1, and returned
 > 	(-1) anyway.  Unfortunately, the code produced by cc (gcc3.4.4)
 > 	at -O2 bears so little resemblance to the source that I
 > 	can't follow it, to point this out explicitly (and
 > 	neither can objdump -S...)
 > 	The code works fine if the gethostname call is made
 > 	without checking the return value (it can't reasonably
 > 	fail, anyway).
 > 	It also works fine if the default -O2 is overridden with
 > 	-O, which is what I'm recommending here.
 > 	It also works fine with default CFLAGS (-O2
 > 	-fno-strict-aliasing -pipe) with CC=3Dgcc41, built from ports.
 >=20
 > >How-To-Repeat:
 > 	cd /usr/ports/sysutils/ucspi-tcp
 > 	sudo make
 > 	cd work/ucspi-tcp-0.88
 > 	./tcpserver 0 2525 /bin/cat
 >=20
 > >Fix:
 >=20
 > 	Well, this is a work-around for this particular case.
 > 	I'm surprised that this could be the only program that
 > 	has trouble at -O2, given the zillions of lines of code
 > 	in the system and ports that seems to be running OK.  So
 > 	I doubt my diagnosis of a compiler bug, but I can't
 > 	think of an alternative.  The code itself looks
 > 	perfectly fine.
 
 So I'm confused, is it using -O2 or -O2 -fno-strict-aliasing (the
 default).  If the former, it's probably an aliasing bug in the source,
 which is why the default is not plain -O2.
 
 Kris
 
 --NzB8fVQJ5HfG6fxh
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.3 (FreeBSD)
 
 iD8DBQFEjiJ2Wry0BWjoQKURAmTPAJ9K395AOYxYbETKAgo8zeTG9g77agCePdRU
 6IYLMaropz+d1U30X/urglo=
 =6U7B
 -----END PGP SIGNATURE-----
 
 --NzB8fVQJ5HfG6fxh--