Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4

From: Bill Davidsen (davidsen_at_tmr.com)
Date: 02/01/04

  • Next message: Bill Davidsen: "Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4" 
    To: linux-kernel@vger.kernel.org
Date:	Sun, 01 Feb 2004 16:17:47 -0500
To: Jakub Jelinek <jakub@redhat.com>

    Jakub Jelinek wrote:
    > On Fri, Jan 30, 2004 at 11:14:07AM -0600, Andy Isaacson wrote:
    >
    >>On Fri, Jan 30, 2004 at 11:35:20AM -0500, James Morris wrote:
    >>
    >>>- const u8 padding[64] = { 0x80, };
    >>>+ static u8 padding[64] = { 0x80, };
    >>
    >>The RedHat bug suggests 'static const' as the appropriate replacement.
    >>
    >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114610#c4
    >>
    >>Unfortunately that probably means an extra 64 bytes of text, rather than
    >>the 10 or so bytes of instructions to do the memset and store. Ideally
    >>padding[] would be allocated in BSS rather than text or the stack (and
    >>initialized with { 0x80, } at runtime), but I guess you can't have
    >>everything.
    >
    >
    > Or you can use
    > u8 padding[64] = { 0x80 };
    > if you really want to initialize it at runtime and want to work around the
    > compiler bug. It shouldn't be any less efficient than
    > const u8 padding[64] = { 0x80 };
    > since it is used just once, passed to non-inlined function.

    I like this, as it avoids bloating the 64 bytes into the kernel. 

    -- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979
-
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/
  • Next message: Bill Davidsen: "Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4"

    Relevant Pages