Messages in this thread | | | Date | Thu, 19 Feb 2009 16:35:44 +0100 | From | Ingo Molnar <> | Subject | Re: 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/
| |