Re: Definition of BUG on x86

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

> Ingo Molnar wrote:
>> * Petr Tesarik <ptesarik@xxxxxxx> wrote:
>>
>>   
>>> Ingo Molnar pÃÅe v Ät 19. 02. 2009 v 13:47 +0100:
>>>     
>>>> * Petr Tesarik <ptesarik@xxxxxxx> wrote:
>>>>
>>>>       
>>>>> Ingo Molnar pÃÅe v Ät 19. 02. 2009 v 13:22 +0100:
>>>>>         
>>>>>> * Petr Tesarik <ptesarik@xxxxxxx> wrote:
>>>>>>
>>>>>>           
>>>>>>> Ingo Molnar pÃÅe v Ät 19. 02. 2009 v 13:10 +0100:
>>>>>>>             
>>>>>>>> * Petr Tesarik <ptesarik@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/