From bvgastel@radagast.home.bitpowder.com  Tue Jan 14 10:14:17 2003
Return-Path: <bvgastel@radagast.home.bitpowder.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E230137B401
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Jan 2003 10:14:17 -0800 (PST)
Received: from radagast.home.bitpowder.com (c38163.upc-c.chello.nl [212.187.38.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 91A7343EB2
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Jan 2003 10:14:11 -0800 (PST)
	(envelope-from bvgastel@radagast.home.bitpowder.com)
Received: from radagast.home.bitpowder.com (localhost [127.0.0.1])
	by radagast.home.bitpowder.com (8.12.6/8.12.6) with ESMTP id h0EIE7fL002611
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Jan 2003 18:14:07 GMT
	(envelope-from bvgastel@radagast.home.bitpowder.com)
Received: (from bvgastel@localhost)
	by radagast.home.bitpowder.com (8.12.6/8.12.6/Submit) id h0EIE6KR002610;
	Tue, 14 Jan 2003 19:14:06 +0100 (CET)
Message-Id: <200301141814.h0EIE6KR002610@radagast.home.bitpowder.com>
Date: Tue, 14 Jan 2003 19:14:06 +0100 (CET)
From: Bernard van Gastel <bvgastel@bitpowder.com>
Reply-To: Bernard van Gastel <bvgastel@bitpowder.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject:
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         47061
>Category:       kern
>Synopsis:       Conflicting system headers illustrated by build of graphics/cqcam
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 14 10:20:07 PST 2003
>Closed-Date:    Sun Aug 22 07:40:04 GMT 2004
>Last-Modified:  Sun Aug 22 07:40:04 GMT 2004
>Originator:     Bernard van Gastel
>Release:        FreeBSD 5.0-RC3 i386
>Organization:
>Environment:
System: FreeBSD radagast.home 5.0-RC3 FreeBSD 5.0-RC3 #0: Tue Jan 14 03:55:37 GMT 2003 root@radagast.home:/usr/src/sys/i386/compile/RADAGAST i386


	Base install of FBSD 5.0 RC3
>Description:
	Conflicting headers (/usr/include/machine/cpufunc.h and /usr/include/strings.h)
	while building graphics/cpcam port.
	Each declare the function `int ffs(int)', in cpufunc.h this function is extern,
	but in strings it's a inline function. I didn't have time to look if it's the system
	headers error or the port's error, so I classified it als medium
>How-To-Repeat:
	build ports/graphics/cqcam
>Fix:
	Commented out the declaration in string.h

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->freebsd-ports 
Responsible-Changed-By: tom 
Responsible-Changed-When: Wed Jan 15 03:15:54 PST 2003 
Responsible-Changed-Why:  
Reassign misfiled Ports PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47061 
State-Changed-From-To: open->suspended 
State-Changed-By: kris 
State-Changed-When: Sun Aug 17 16:23:20 PDT 2003 
State-Changed-Why:  
Known problem, awaiting fix 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47061 
Responsible-Changed-From-To: freebsd-ports-bugs->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Dec 23 16:58:02 PST 2003 
Responsible-Changed-Why:  
I guess no one is going to fix this unless I do it ... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47061 
State-Changed-From-To: suspended->open 
State-Changed-By: linimon 
State-Changed-When: Tue Dec 23 20:24:45 PST 2003 
State-Changed-Why:  
This is really a kernel problem that can only be worked around 
in the ports collection with terrible hackery.  I'm going to go 
ahead and do that to unbreak graphics/cqcam and one or two other 
ports that suffer from this, but this is by no means an acceptable 
long-term solution for many reasons.  See extensive comments in 
the audit trail. 


Responsible-Changed-From-To: linimon->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Dec 23 20:24:45 PST 2003 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=47061 

From: Mark Linimon <linimon@lonesome.com>
To: freebsd-gnats-submit@FreeBSD.org, bvgastel@bitpowder.com
Cc:  
Subject: Re: ports/47061: Conflicting system headers by build of graphics/cqcam
Date: Tue, 23 Dec 2003 22:24:20 -0600

 This is really a kernel problem.  I am going to go ahead and commit a
 workaround for this and the one or two other ports with this problem --
 but the workaround is basically unacceptable.
 
 The underlying problem is that machine/cpufunc.h for i386 has had
 a definition for a machine function 'ffs' for, oh, say, about 9 years
 now.  However, man ffs will show you that there is an ffs(3) function
 as well.  Even after reading the source it's not clear to me if these
 are supposed to have the same purpose -- someone with a more intimate
 knowledge of i386 arch is going to have to rule for certain.
 
 Back in 2002 a commit was done to create 'strings.h' to provide
 better adherance to POSIX.  When this was done, a prototype for
 ffs() was introduced for ffs(3).  These prototypes fight with each
 other.  From user code, there appears to be no way (to me) to
 allow access to both.  However, this port, among others, wishes
 to use the strings.h definitions _and_ the inb() and outb()
 functions which only cpufunc.h provides.
 
 The only way to (correctly) fix this has to do with changes to
 the include files, and that's outside the charter of the ports folks.
 
 In the meantime, I'm going to hold my nose and commit an include
 file to the port that is merely the inb/outb functions.  This is
 clearly a hack that should go away once a "correct" solution is found.
 
 mcl
 

From: Bruce Evans <bde@zeta.org.au>
To: Mark Linimon <linimon@lonesome.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: ports/47061: Conflicting system headers by build of graphics/cqcam
Date: Wed, 24 Dec 2003 21:14:55 +1100 (EST)

 On Tue, 23 Dec 2003, Mark Linimon wrote:
 
 >  This is really a kernel problem.  I am going to go ahead and commit a
 >  workaround for this and the one or two other ports with this problem --
 >  but the workaround is basically unacceptable.
 
 Er, this is really a port[s] problem.  <machine/cpufunc.h> is not intended
 to be included by applications.  There was never any conflict with <string.h>
 in the kernel because the kernel never included <string.h>, and the kernel
 now avoids bogus conflicts, if any, with gcc's builtin ffs() using
 -fno-builtin.
 
 >  The underlying problem is that machine/cpufunc.h for i386 has had
 >  a definition for a machine function 'ffs' for, oh, say, about 9 years
 >  now.  However, man ffs will show you that there is an ffs(3) function
 >  as well.  Even after reading the source it's not clear to me if these
 >  are supposed to have the same purpose -- someone with a more intimate
 >  knowledge of i386 arch is going to have to rule for certain.
 
 They are the same.  Last time I checked (less than a year ago), the gcc
 builtin was still slower than the kernel inline except possibly when the
 latter can use non-base-arch instructions like cmov.  amd64's always have
 cmov and always use the builtin.
 
 ... I checked again.  With the following slightly too simple test:
 
 %%%
 #include <sys/types.h>
 #include <machine/cpufunc.h>
 
 int z[4096];
 
 main()
 {
 	volatile int v;
 	int i, j;
 
 	for (i = 0; i < 4096; i++)
 		z[i] = 1 << rand();	/* Yes, this is sloppy. */
 	for (j = 0; j < 100000; j++)
 		for (i = 0; i < 4096; i++)
 #ifdef NOBUILTIN
 			v = ffs(z[i]);
 #else
 			v = __builtin_ffs(z[i]);
 #endif
 }
 %%%
 
 Times on an Athlon XP1600 overclocked by 146/133:
 
 cc -O -mcpu=pentiumpro -o foo foo.c (default from bsd.cpu.mk)
         3.49 real         3.47 user         0.00 sys
 cc -O -mcpu=pentiumpro -DNOBUILTIN -o foo foo.c (default + kernel ffs())
         3.21 real         3.21 user         0.00 sys
 cc -O -march=pentiumpro -o foo foo.c (gives cmov and works on Athlon XP too):
         3.21 real         3.21 user         0.00 sys
 
 Here using cmov[e] gives the same amount of optimization as the kernel ffs()
 gets by using a simple conditional branch instead of a slow instruction
 sequence starting with "set"[e].  Mispredicted branches are expensive on
 some arches, but apparently they aren't on Athlons.  The rand() in the
 test was intended to cause mispredicted branches as well as lengthy
 searches, but it doesn't actually.  The branch is never taken since
 z[i] is never 0.  On changing the initialization of z[i] so that the
 branch is taken every second time:
 
 		if (i & 1)
 			z[i] = 1 << rand();
 
 the kernel version becomes much faster:
 
         2.01 real         2.00 user         0.00 sys
 
 and the other times don't change significantly.  This is presumably
 because the Athlon predicts taking the branch every second time
 perfectly.  The bit-search instruction is very expensive (and always
 takes the same time??) and by branching over it every second time the
 cost per iteration is almost halved.
 
 A better benchmark might randomize the branches, but this might be
 evey further from real applications since an arg of 0 may be very
 unlikely (or very likely).
 
 Times on a Celeron 366:
 gcc builtin without cmov (very slow!):
        15.78 real        15.68 user         0.00
 gcc builtin with cmov:
         5.64 real         5.61 user         0.00
 kernel ffs():
         5.85 real         5.81 user         0.00
 kernel ffs() with alternating 0's (again, others not affected by alternating):
         5.62 real         5.58 user         0.00
 
 Times on an amd64 (sledge = Opteron 244 1804 MHz)
 
 gcc builtin with cmov:
         2.73 real         2.72 user         0.00 sys
 old kernel ffs():
         3.42 real         3.39 user         0.01 sys
 kernel ffs() with alternating 0's (again, builtin affected by alternating):
         1.82 real         1.82 user         0.00 sys
 
 So using cmov is actually significtly better than a simple branch on
 amd64's, but only if the arg isn't often 0.
 
 >  In the meantime, I'm going to hold my nose and commit an include
 >  file to the port that is merely the inb/outb functions.  This is
 >  clearly a hack that should go away once a "correct" solution is found.
 
 This is approximately correct, not a hack.  The system could provide
 a header that implements inb() and outb() functions for userland (*),
 but <machine/cpufunc.h> is not this header.  It's just a bit much for
 multiple applications to have to duplicate these interfaces.
 
 (*) They shouldn't exist in the kernel.  Bus-space should be used.
 
 Bruce

From: Mark Linimon <linimon@lonesome.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: ports/47061: Conflicting system headers by build of graphics/cqcam
Date: Wed, 24 Dec 2003 04:54:12 -0600

 >
 >
 >Er, this is really a port[s] problem [...]
 >
 >The system could provide
 >a header that implements inb() and outb() functions for userland (*),
 >but <machine/cpufunc.h> is not this header.
 >
 Other than duplicating the inb/outb code into places in the ports 
 collection,
 there is no way that I can see for the ports collection to fix this problem;
 it involves some kind of change to the system headers.  So, I'm saying that
 I agree with point (2) but that IMHO (2) is necessarily in conflict with 
 (1).
 
 If you have some other suggestion about getting inb/outb functionality into
 the ports, please make it.  (Fair warning: "rewrite or delete the apps" 
 is not
 what I'm looking for :-) ... unless you're also willing to replace the junky
 old parallel-port peripherals that these ports talk to).
 
 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Sun Aug 22 07:39:39 GMT 2004 
State-Changed-Why:  
A workaround for this problem was committed around 2 months ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47061 
>Unformatted:
