From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757793AbZBSPgQ (ORCPT ); Thu, 19 Feb 2009 10:36:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751748AbZBSPgA (ORCPT ); Thu, 19 Feb 2009 10:36:00 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:47889 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340AbZBSPgA (ORCPT ); Thu, 19 Feb 2009 10:36:00 -0500 Date: Thu, 19 Feb 2009 16:35:44 +0100 From: Ingo Molnar To: Jeremy Fitzhardinge Cc: Petr Tesarik , "H. Peter Anvin" , LKML Subject: Re: Definition of BUG on x86 Message-ID: <20090219153544.GA31637@elte.hu> References: <499C4786.5010504@goop.org> <1235043648.15053.35.camel@nathan.suse.cz> <20090219121027.GB1703@elte.hu> <1235045971.15053.42.camel@nathan.suse.cz> <20090219122211.GE1703@elte.hu> <1235047082.15053.49.camel@nathan.suse.cz> <20090219124702.GC22044@elte.hu> <1235048535.15053.52.camel@nathan.suse.cz> <20090219144902.GA8650@elte.hu> <499D7B9D.7060001@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <499D7B9D.7060001@goop.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: >> * Petr Tesarik wrote: >> >> >>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:47 +0100: >>> >>>> * Petr Tesarik wrote: >>>> >>>> >>>>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:22 +0100: >>>>> >>>>>> * Petr Tesarik wrote: >>>>>> >>>>>> >>>>>>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:10 +0100: >>>>>>> >>>>>>>> * Petr Tesarik 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