lkml.org 
[lkml]   [2009]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Definition of BUG on x86

    * Jeremy Fitzhardinge <jeremy@goop.org> wrote:

    > Ingo Molnar wrote:
    >> * Petr Tesarik <ptesarik@suse.cz> wrote:
    >>
    >>
    >>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:47 +0100:
    >>>
    >>>> * Petr Tesarik <ptesarik@suse.cz> wrote:
    >>>>
    >>>>
    >>>>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:22 +0100:
    >>>>>
    >>>>>> * Petr Tesarik <ptesarik@suse.cz> wrote:
    >>>>>>
    >>>>>>
    >>>>>>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:10 +0100:
    >>>>>>>
    >>>>>>>> * Petr Tesarik <ptesarik@suse.cz> wrote:
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>> So, the only method I could invent was using gas macros.
    >>>>>>>>> It works but is quite ugly, because it relies on the
    >>>>>>>>> actual assembler instruction which is generated by the
    >>>>>>>>> compiler. Now, AFAIK gcc has always translated "for(;;)"
    >>>>>>>>> into a jump to self, and that with any conceivable
    >>>>>>>>> compiler options, but I don't know anything about Intel
    >>>>>>>>> cc.
    >>>>>>>>> +static inline __noreturn void
    >>>>>>>>> discarded_jmp(void)
    >>>>>>>>> +{
    >>>>>>>>> + asm volatile(".macro jmp target\n"
    >>>>>>>>> + "\t.purgem jmp\n"
    >>>>>>>>> + ".endm\n");
    >>>>>>>>> + for (;;) ;
    >>>>>>>>> +}
    >>>>>>>>>
    >>>>>>>> hm, that's very fragile.
    >>>>>>>>
    >>>>>>>> Why not just:
    >>>>>>>>
    >>>>>>>> static inline __noreturn void x86_u2d(void)
    >>>>>>>> {
    >>>>>>>> asm volatile("u2d\n");
    >>>>>>>> }
    >>>>>>>>
    >>>>>>>> If GCC emits a bogus warning about _that_, then it's a bug
    >>>>>>>> in the compiler that should be fixed.
    >>>>>>>>
    >>>>>>> I wouldn't call it a bug. The compiler has no idea about what
    >>>>>>> the inline assembly actualy does. So it cannot recognize that
    >>>>>>> the ud2 instruction does not return (which BTW might not even
    >>>>>>> be the case, depending on the implementation of the Invalid
    >>>>>>> Opcode exception).
    >>>>>>>
    >>>>>> No, i'm not talking about the inline assembly.
    >>>>>>
    >>>>>> I'm talking about the x86_u2d() _inline function_, which has
    >>>>>> the __noreturn attribute.
    >>>>>>
    >>>>>> Shouldnt that be enough to tell the compiler that it ... wont
    >>>>>> return?
    >>>>>>
    >>>>> Nope, that's not how it works.
    >>>>>
    >>>>> You _may_ specify a noreturn attribute to any function (and GCC
    >>>>> will honour it AFAICS), but if GCC _thinks_ that the function
    >>>>> does return, it will issue the above-mentioned warning:
    >>>>>
    >>>>> /usr/src/linux-2.6/arch/x86/include/asm/bug.h:10: warning: 'noreturn' function does return
    >>>>>
    >>>>> And that's what your function will do. :-(
    >>>>>
    >>>>> Yes, I also thinks that this behaviour is counter-intuitive.
    >>>>> Besides, I haven't found a gcc switch to turn this warning off,
    >>>>> which would be my next recommendation, since the GCC heuristics
    >>>>> is broken, of course.
    >>>>>
    >>>> so GCC should be fixed and improved here, on several levels.
    >>>>
    >>> Agree.
    >>>
    >>> But it takes some time, even if we start pushing right now. What's
    >>> your suggestion for the meantime? Keep the dummy jmp? And in case
    >>> anybody is concerned about saving every byte in the text section,
    >>> they can apply my dirty patch?
    >>>
    >>> Actually, this doesn't sound too bad.
    >>>
    >>
    >> yeah. Please forward the problem to the appropriate GCC list in any
    >> case.
    >>
    >>
    >
    > I think the official answer for this case is to use __builtin_trap. But:
    >
    > -- Built-in Function: void __builtin_trap (void)
    > This function causes the program to exit abnormally. GCC
    > implements this function by using a target-dependent mechanism
    > (such as intentionally executing an illegal instruction) or by
    > calling `abort'. ***The mechanism used may vary from release to
    > release so you should not rely on any particular implementation.***
    >
    > which in principle is hard for us to make use of. In practice I think
    > it has always been ud2a on x86.

    could we just do:

    __builtin_trap();
    for (;;);

    and _now_ GCC would optimize away the infinite loop? And if it
    does something silly in a future release, we'd either get a
    build error or we'd run into the infinite loop for sure.

    Ingo
    --
    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/

    \
     
     \ /
      Last update: 2009-02-19 16:39    [W:2.982 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site