From owner-freebsd-ports@FreeBSD.ORG Fri Jun 4 05:30:12 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E9C1065675 for ; Fri, 4 Jun 2010 05:30:12 +0000 (UTC) (envelope-from snabb@epipe.com) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA2D8FC13 for ; Fri, 4 Jun 2010 05:30:12 +0000 (UTC) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by tiktik.epipe.com (8.14.3/8.14.3) with ESMTP id o545U86n018037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jun 2010 05:30:09 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o545U86n018037 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1275629409; x=1276234209; bh=Oat+KLjwC71Vzm8S5HInEsCp7/kGJQ9ciaHzVtybX7E=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=aUIIVzLbKjOhZRYrMDSxUG1us9zMdDm4U02PeCHMI4MvIqN/HILKPA0Z02ImifmtX 6MYhEHs3ioIqrwT5ygN2fD4YtmaxGrOjd+WZjo5z//7gwIK22SATLHqzeslh0R5ei+ ccPGm8Jhm6BO/6/TmhulwlBK20GNkymSxtWroo1M= Date: Fri, 4 Jun 2010 05:30:03 +0000 (UTC) From: Janne Snabb To: Dmitry Marakasov In-Reply-To: <20100602192000.GE21354@hades.panopticon> Message-ID: References: <20100602192000.GE21354@hades.panopticon> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.5 (tiktik.epipe.com [IPv6:2001:470:8940:10::1]); Fri, 04 Jun 2010 05:30:09 +0000 (UTC) Cc: freebsd-ports@freebsd.org Subject: Re: Building ports with stack-protector X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 05:30:12 -0000 On Wed, 2 Jun 2010, Dmitry Marakasov wrote: > I'd perfer variables to be named and to work similarily to existing > MAKE_JOBS framework. Me too. Makes sense. The variable names in my original example were intended for illustrative purposes only. > AFAIR there was certain performance penalty with stack-protector, I think the penalty is small enough. I would assume that someone has already made an evaluation on this before turning it on in "make buildworld". I was earlier trying to search for a discussion on it, but I did not find it on the public mailing lists. Maybe it is somewhere. > It may be implemented by mere copypasting MAKE_JOBS implementation, > like this: http://people.freebsd.org/~amdmi3/stack-protector.patch It looks good to me. Simple enough. It would be nice to see this committed. > Also note, that unlike MAKE_JOBS (for which build failures are > non-deterministic), this can probably be tested with a single exp-run > and all ports marked with STACK_PROTECTOR_{UN,}SAFE. If that's > considered useful enough as well. STACK_PROTECTOR_UNSAFE could be automatically added in many cases where it is needed (if either the port itself or if something that depends on it fails). But based on my experience, STACK_PROTECTOR_SAFE should not be added based on a mere build check. I remember that some ports built fine but the resulting binaries would not work for various reasons when I did my CFLAGS+=-fstack-protector experiment a couple of months ago. Unfortunately at that time I did not keep a record of which ports were problematic (and I built && tested only a small subset of ports which were the most relevant to myself, most of them being network facing server programs). IMHO there should be some sort of human testing effort to mark ports STACK_PROTECTOR_SAFE, to which I could certainly contribute. One question is: does it make sense to send-pr this information for each port, or should the testing results be communicated through some alternative channel so that the gnats will not be overwhelmed by PRs related to this (the total number of ports is quite high). Before starting human testing for STACK_PROTECTOR_SAFE an automatic test and flagging for STACK_PROTECTOR_UNSAFE is needed. Otherwise too much of the testing effort goes to marking UNSAFEs which can be easily determined with an automated test. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/