lkml.org 
[lkml]   [2011]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c
    On 06/14/2011 01:43 PM, Rakib Mullick wrote:
    > On Tue, Jun 14, 2011 at 12:06 AM, Andrew Lutomirski<luto@mit.edu> wrote:
    >> On Mon, Jun 13, 2011 at 4:45 AM, Rakib Mullick<rakib.mullick@gmail.com> wrote:
    >>> On Mon, Jun 13, 2011 at 10:54 AM, Rakib Mullick<rakib.mullick@gmail.com> wrote:
    >>>> On Mon, Jun 13, 2011 at 8:52 AM, Andrew Lutomirski<luto@mit.edu> wrote:
    >>>>> On Sun, Jun 12, 2011 at 1:12 AM, Rakib Mullick<rakib.mullick@gmail.com> wrote:
    >>>>>> On Sat, Jun 11, 2011 at 5:01 PM, Andrew Lutomirski<luto@mit.edu> wrote:
    >>>>>>> On Sat, Jun 11, 2011 at 3:31 AM, Rakib Mullick<rakib.mullick@gmail.com> wrote:
    >>>>>
    >>>>> I think there are three separate issues here:
    >>>>>
    >>>>> 1. Can ret be used uninitialized? I say no, even as seen by the
    >>>>> compiler. If vsyscall_nr is 0, 1, or 2, then ret is initialized. If
    >>>>> vsyscall_nr is 3, then the BUG gets hit. BUG is defined as some
    >>>>> assembly magic followed by unreachable(), and the compiler is supposed
    >>>>> to know that code after unreachable() is qunreachable. So how can ret
    >>>>> be used uninitialized?
    >>>>>
    >>>> I don't have much knowledge of advance assembly, so I really don't
    >>>> understand that part - how BUG handles this. If it really makes sure
    >>>> that, it will handle it properly then I think you can drop this patch.
    >>>>
    >>>>> What version of gcc do you have? gcc (GCC) 4.6.0 20110530 (Red Hat
    >>>>> 4.6.0-9) does not produce this warning.
    >>>>>
    >>>> Currently, I'm replying from outside my home. I'll let you know when
    >>>> I'm back home.
    >>>>
    >>> Here is my GCC version - gcc version 4.5.1 20100924 (Red Hat 4.5.1-4)
    >>> (GCC). I'm using Fedora 14.
    >>
    >> I also have gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) on another box,
    >> and I still can't reproduce this.
    >>
    >> Can you tell me which git revision you're building and send me your
    >> .config and the output of:
    >>
    > I'm using 3.0.0-rc2 (lastly I pulled tip tree 3 days ago). I've
    > attached the .config (config.log).
    >
    >> $ touch arch/x86/kernel/vsyscall_64.o
    >> $ make V=1 arch/x86/kernel/vsyscall_64.o
    >>
    > Output of the above steps are attached (vsyscall_64.log). Hope that will help.

    Aha! You have CONFIG_BUG=n. I'm not sure that fixing warnings for that
    case is worth it (or is even a good idea).

    Can you try this patch, though:

    Signed-off-by: Andy Lutomirski <luto@mit.edu>

    diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
    index dfb0ec6..f4083f4 100644
    --- a/include/asm-generic/bug.h
    +++ b/include/asm-generic/bug.h
    @@ -107,11 +107,11 @@ extern void warn_slowpath_null(const char *file,
    const int line);

    #else /* !CONFIG_BUG */
    #ifndef HAVE_ARCH_BUG
    -#define BUG() do {} while(0)
    +#define BUG() do { unreachable(); } while(0)
    #endif

    #ifndef HAVE_ARCH_BUG_ON
    -#define BUG_ON(condition) do { if (condition) ; } while(0)
    +#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
    #endif

    #ifndef HAVE_ARCH_WARN_ON
    It may silence a lot of warnings, although it'll come at a cost of
    increased code size with CONFIG_BUG=n on older gcc. On newer GCC,
    you'll get possibly faster and smaller code.

    --Andy


    \
     
     \ /
      Last update: 2011-06-14 20:05    [W:0.029 / U:3.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site