From owner-freebsd-current@FreeBSD.ORG Sat Jun 12 16:32:25 2010 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 556BA1065672 for ; Sat, 12 Jun 2010 16:32:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B5DA48FC12 for ; Sat, 12 Jun 2010 16:32:24 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o5CGWLSa066614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 18:32:21 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o5CGW9jb001839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jun 2010 18:32:09 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o5CGW9sh096162; Sat, 12 Jun 2010 18:32:09 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o5CGW9i0096161; Sat, 12 Jun 2010 18:32:09 +0200 (CEST) (envelope-from ticso) Date: Sat, 12 Jun 2010 18:32:08 +0200 From: Bernd Walter To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , current@freebsd.org Message-ID: <20100612163208.GS87112@cicely7.cicely.de> References: <20100611162118.GR39829@acme.spoerlein.net> <867hm5tl6u.fsf@ds4.des.no> <20100612153526.GA3632@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100612153526.GA3632@acme.spoerlein.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Subject: Re: Cleanup for cryptographic algorithms vs. compiler optimizations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 16:32:25 -0000 On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote: > On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote: > > Ulrich Spörlein writes: > > > optimizing compilers have a tendency to remove assignments that have > > > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of > > > zeroing variables, which is however optimized away. [...] Is there a > > > canonical way to zero those variables and should we use them (memset > > > perhaps? what are the performance implications?) > > > > If you stick these variables in a struct, you can memset the struct to > > zero them; if there are many of them, it may be faster than zeroing them > > individually. > > > > Alternatively, you can use something like this: > > > > #define FORCE_ASSIGN(type, var, value) \ > > *(volatile type *)&(var) = (value) > > Interesting trick, thanks. I'll try this ... I'm not sure when removing a memset is allowed. Maybe passing volatile pointers might be enough. And I'm happy to be corrected from in deep experts - my knowledge is more from practical microcontroller programming. The problem with memset is that is is inlined by at least gcc and inlined functions are included in the optimizations. But calling my_abolsutely_not_inlineable_memset should work IMHO. In other words: declare a local memset function, which is declared (in compiler specific words) as not being inlineable, which itself calls memset you should be safe, since the function doesn't know why it does the memset it can't be removed and the caller doesn't know anything about the called function. A portible way would be to have this function in a separate .c file, which prohibits inlining. C++ has the concept of volatile member functions, but this is a slightly different thing. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.