lkml.org 
[lkml]   [2016]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning
On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> 0000000000000000 <bar>:
>> 0: 55 push %rbp
>> 1: 48 89 e5 mov %rsp,%rbp
>> 4: 53 push %rbx
>> 5: 50 push %rax
>> 6: e8 00 00 00 00 callq b <bar+0xb>
>> b: ff 0d 00 00 00 00 decl 0x0(%rip) # 11 <bar+0x11>
>> 11: 9c pushfq
>> 12: 5b pop %rbx
>> 13: e8 00 00 00 00 callq 18 <bar+0x18>
>> 18: b8 01 00 00 00 mov $0x1,%eax
>> 1d: 53 push %rbx
>> 1e: 9d popfq
>> 1f: 75 07 jne 28 <bar+0x28>
>
>
> Yeah, the above is pure garbage.
>
>> So, the issue is still alive.
>>
>> What do you mean by "for the kernel we at a minimum need a way to
>> disable that code generation"?
>> Can this be fixed in the Linux-kernel?
>
> No. This will never be fixed in the kernel. It's a compiler bug.
>
> The compiler generates shit code. It's absolutely atrociously bad even
> if you ignore any kernel issues, because that kind of code just
> performs badly (the compiler should have used "setcc" or something
> similar to just set the comparison value, not save and restore eflags.
>
> And quite frankly, any compiler writer that thinks it is good code is
> not somebody I want touching a compiler that the kernel depends on
> anyway.
>
> But it is not just bad code for the kernel, it's actively buggy code,
> since it corrupts the IF.
>
> Until this gets fixed in LLVM, there's no way in hell that we will
> ever have a kernel compiled with that piece of shit.
>
> Really. If the LLVM developers cannot fix their crap code generation,
> it's not worth touching that shit with a ten-foot pole.
>
> I'd love to be able to compile the kernel with LLVM, but the fact that
> the broken eflags code apparently _still_ hasn't been fixed makes me
> just go "not worth it".
>
> And if the LLVM developers don't see this as an obvious bug, it's even
> less worth it - because that shows not just that the compiler is
> broken, but that the developers involved with it are broken too.
>

Thanks for the quick answer.

I just grepped for some "buzzwords" people gave me in this
email-thread and I was looking at (llvm.git HEAD - upcoming v3.9
release) and found these comments in [1]

[ lib/Target/X86/X86InstrInfo.cpp ]

void X86InstrInfo::copyPhysReg()
...
// PUSHF/POPF is also potentially incorrect because it affects other flags
// such as TF/IF/DF, which LLVM doesn't model.
...

- Sedat -

[1] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X86/X86InstrInfo.cpp#L4516

\
 
 \ /
  Last update: 2016-06-27 23:01    [W:0.093 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site