From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758487AbZBSPc5 (ORCPT ); Thu, 19 Feb 2009 10:32:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752894AbZBSPcs (ORCPT ); Thu, 19 Feb 2009 10:32:48 -0500 Received: from gw.goop.org ([64.81.55.164]:56866 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752198AbZBSPcr (ORCPT ); Thu, 19 Feb 2009 10:32:47 -0500 Message-ID: <499D7B9D.7060001@goop.org> Date: Thu, 19 Feb 2009 07:32:45 -0800 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ingo Molnar CC: Petr Tesarik , "H. Peter Anvin" , LKML Subject: Re: Definition of BUG on x86 References: <1234975856.15053.16.camel@nathan.suse.cz> <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> In-Reply-To: <20090219144902.GA8650@elte.hu> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html J