From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758491AbZBSMr0 (ORCPT ); Thu, 19 Feb 2009 07:47:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753827AbZBSMrQ (ORCPT ); Thu, 19 Feb 2009 07:47:16 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:41800 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753776AbZBSMrP (ORCPT ); Thu, 19 Feb 2009 07:47:15 -0500 Date: Thu, 19 Feb 2009 13:47:02 +0100 From: Ingo Molnar To: Petr Tesarik Cc: "H. Peter Anvin" , Jeremy Fitzhardinge , LKML Subject: Re: Definition of BUG on x86 Message-ID: <20090219124702.GC22044@elte.hu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1235047082.15053.49.camel@nathan.suse.cz> 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 * 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. Ingo