Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262705AbUA3SIZ (ORCPT ); Fri, 30 Jan 2004 13:08:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262707AbUA3SIY (ORCPT ); Fri, 30 Jan 2004 13:08:24 -0500 Received: from fw.osdl.org ([65.172.181.6]:16095 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S262705AbUA3SIW convert rfc822-to-8bit (ORCPT ); Fri, 30 Jan 2004 13:08:22 -0500 Date: Fri, 30 Jan 2004 10:02:47 -0800 From: "Randy.Dunlap" To: James Morris Cc: arnd@arndb.de, linux-kernel@vger.kernel.org, rspchan@starhub.net.sg Subject: Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4 Message-Id: <20040130100247.1a0f6eb9.rddunlap@osdl.org> In-Reply-To: References: <200401301643.13477.arnd@arndb.de> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2454 Lines: 57 On Fri, 30 Jan 2004 11:57:20 -0500 (EST) James Morris wrote: | On Fri, 30 Jan 2004, Arnd Bergmann wrote: | | > James Morris wrote: | > > Have you noticed if this happens for any of the other crypto algorithms? | > | > Just as a reminder, there is still an issue with extreme stack usage | > of some of the algorithms, depending on compiler version and | > flags. | > | > The worst I have seen was around 16kb for twofish_setkey on 64 bit | > s390 with gcc-3.1 (iirc). Right now, I get up to 4kb for this | > function with gcc-3.3.1, which probably works but is definitely | > a bad sign. I've seen this as well on other architectures (iirc | > on x86_64), but not as severe. | > | > Other algorithms are bad as well, these are the top scores from | > J?rn Engel's checkstack.pl (s390 64bit 2.6.1 gcc-3.3.1): | > | > 0x00000a twofish_setkey: lay %r15,-3960(%r15) | > 0x0026fc aes_decrypt: lay %r15,-1168(%r15) | > 0x000c0c aes_encrypt: lay %r15,-1000(%r15) | > 0x00000e sha512_transform: lay %r15,-936(%r15) | > 0x001292 test_deflate: lay %r15,-784(%r15) | > 0x0028a2 cast6_decrypt: lay %r15,-696(%r15) | > 0x00d1a0 twofish_encrypt: lay %r15,-664(%r15) | > 0x001b34 setkey: lay %r15,-656(%r15) | > 0x00e2b0 twofish_decrypt: lay %r15,-624(%r15) | > 0x000c9e cast6_encrypt: lay %r15,-600(%r15) | > 0x000014 sha1_transform: lay %r15,-504(%r15) | | I'm not seeing anything like this on x86 (e.g. stack usage is 8 bytes), | and can't see an obvious way to fix the problem for your compiler. Here's what I see on x86 and gcc 3.2 (for Linux 2.6.1). What Linux version of the code are you looking at? $0x180,%esp: c01fd5aa $0x1b0,%esp: c01fecfa $0x230,%esp: c0206acd $0x10c,%esp: c0205c90 $0x1fc,%esp: c01e9ed8 $0x120,%esp: c01eb842 $0x384,%esp: c01ed988 $0x10c,%esp: c01f1c90 -- ~Randy kernel-janitors project: http://janitor.kernelnewbies.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/