Re: Definition of BUG on x86

Ingo Molnar
2009-02-19T15:36:16Z

* 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