On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds
wrote:
> On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> Does this now look good?
>
> Looks fine to me. The instruction choice is still pretty odd:
>
> 1a: f6 c3 fftest $0xff,%bl
> 1
On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote:
>
> $ objdump -S clang-eflag.o
>
> Does this now look good?
Looks fine to me. The instruction choice is still pretty odd:
1a: f6 c3 fftest $0xff,%bl
1d: 74 02 je 21
that "test $0xff,%bl" is a
On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek wrote:
> On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
> wrote:
>> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote:
>>>
>>> $ objdump -S clang-eflag.o
>>>
>>> clang-eflag.o: file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .text:
On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> :
>>0: 55 push
On Mon, Jun 27, 2016 at 1:27 PM, Sedat Dilek wrote:
>
> 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]
>
>
> [1]
> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X
On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> :
>>0: 55 push
On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote:
>
> $ objdump -S clang-eflag.o
>
> clang-eflag.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> :
>0: 55 push %rbp
>1: 48 89 e5mov%rsp,%rbp
>4:
On Mon, Jun 27, 2016 at 9:50 PM, Sedat Dilek wrote:
> On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds
> wrote:
>> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern
>> wrote:
>>>
>>> Of course, there are other ways to save a single flag value (such as
>>> setz). It's up to the compiler developers to d
On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds
wrote:
> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote:
>>
>> Of course, there are other ways to save a single flag value (such as
>> setz). It's up to the compiler developers to decide what they think is
>> best.
>
> Using 'setcc' to save eflag
On Mon, 7 Mar 2016 10:04:21 -0800
Andy Lutomirski wrote:
> > Exactly. The compiler may get away with this in userspace (maybe), but
> > for the kernel, it is definitely a show stopper. Especially if it knows
> > that an asm() may be called.
>
> It's broken for user code that fiddles with AC,
On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote:
>
> Of course, there are other ways to save a single flag value (such as
> setz). It's up to the compiler developers to decide what they think is
> best.
Using 'setcc' to save eflags somewhere is definitely the right thing to do.
Using pushf/po
On Mon, 7 Mar 2016, David Laight wrote:
> From: Sedat Dilek
> ...
> > Did someone look at the next/follow-ups in this thread?
> > For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
>
> LAHF and SAHF come with the following note:
>
> This instruction executes as described above i
On Mon, Mar 7, 2016 at 9:30 AM, Steven Rostedt wrote:
> On Mon, 7 Mar 2016 18:24:12 +0100 (CET)
> Jiri Kosina wrote:
>
>> > So, if Clang is producing wrong X86 code here, is it possible to turn
>> > interrupts on/off manually? But, hmm that affects other places as well
>> > in the Linux sources,
From: Sedat Dilek
...
> Did someone look at the next/follow-ups in this thread?
> For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
LAHF and SAHF come with the following note:
This instruction executes as described above in compatibility mode and legacy
mode.
It is valid in 64-
On Mon, 7 Mar 2016 18:24:12 +0100 (CET)
Jiri Kosina wrote:
> > So, if Clang is producing wrong X86 code here, is it possible to turn
> > interrupts on/off manually? But, hmm that affects other places as well
> > in the Linux sources, so.
>
> This issue needs to be handled in the compiler.
>
On Mon, 7 Mar 2016, Sedat Dilek wrote:
> Did someone look at the next/follow-ups in this thread?
> For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
Using LAHF/SAHF would "solve" it, as IF is at bit #9. The question is
whether they need to play with flags here at all.
On Mon,
On Mon, Mar 7, 2016 at 5:41 PM, Alan Stern wrote:
> On Mon, 7 Mar 2016, Sedat Dilek wrote:
>
>> Hmm, we are there where I was looking at...
>>
>> Please, read the reply of Jiri [1], we did some tweaking.
>> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
>
> Yes, Jiri was looking more or less at
On Mon, Mar 7, 2016 at 6:05 PM, Jiri Kosina wrote:
> On Mon, 7 Mar 2016, Alan Stern wrote:
>
>> > 319: 9c pushfq
>> > 31a: 41 5c pop%r12
>> > 31c: 48 89 dfmov%rbx,%rdi
>> > 31f: e8 00 00 00 0
On Mon, 7 Mar 2016 11:41:37 -0500 (EST)
Alan Stern wrote:
> It's hard to call this a compiler bug, but perhaps it is -- I don't
> know how programmers are supposed to tell CLANG that a subroutine
> modifies the Interrupt Flag in a way that the compiler shouldn't mess
> up.
I would state that t
On Mon, 7 Mar 2016, Alan Stern wrote:
> > 319: 9c pushfq
> > 31a: 41 5c pop%r12
> > 31c: 48 89 dfmov%rbx,%rdi
> > 31f: e8 00 00 00 00 callq 324
> > 324: 41 54
On Mon, 7 Mar 2016 11:41:37 -0500 (EST)
Alan Stern wrote:
> It's hard to call this a compiler bug, but perhaps it is -- I don't
> know how programmers are supposed to tell CLANG that a subroutine
> modifies the Interrupt Flag in a way that the compiler shouldn't mess
> up.
Really! This is what'
On Mon, 7 Mar 2016, Sedat Dilek wrote:
> Hmm, we are there where I was looking at...
>
> Please, read the reply of Jiri [1], we did some tweaking.
> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
Yes, Jiri was looking more or less at the right place but his
conclusions were wrong.
> *** Part
On Mon, Mar 7, 2016 at 4:59 PM, Sedat Dilek wrote:
> On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote:
>> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>>
>>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern
>>> wrote:
>>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>> >
>>> >> On 3/1/16, Alan Stern wrote:
>
On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote:
> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>
>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern wrote:
>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>> >
>> >> On 3/1/16, Alan Stern wrote:
>> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
>> >> >
>> >> >> On
On Sat, 5 Mar 2016, Sedat Dilek wrote:
> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern wrote:
> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
> >
> >> On 3/1/16, Alan Stern wrote:
> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
> >> >
> >> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
> >> >> wrote:
On Wed, 2 Mar 2016, Sedat Dilek wrote:
> On 3/1/16, Alan Stern wrote:
> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
> >
> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
> >> wrote:
> >> > On Sat, 3 Oct 2015 12:05:42 +0200
> >> > Sedat Dilek wrote:
> >> >
> >> >> So, at the beginning... dunno W
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Peter Zijlstra wrote:
>> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>>> 8110f570 :
>>> 8110f570: 55 push %rbp
>>> 8110f571: 48 89 e5mov%rsp,%rbp
>>> 8110f574
On Wed, Mar 02, 2016 at 11:35:35AM -0500, Steven Rostedt wrote:
> On Wed, 2 Mar 2016 17:24:12 +0100
> Peter Zijlstra wrote:
>
> > On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> > > 8110f570 :
> > > 8110f570: 55 push %rbp
> > > 8110f57
On 3/2/16, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>> 8110f570 :
>> 8110f570:55 push %rbp
>> 8110f571:48 89 e5mov%rsp,%rbp
>> 8110f574:41 57 push
On Wed, 2 Mar 2016 17:24:12 +0100
Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> > 8110f570 :
> > 8110f570: 55 push %rbp
> > 8110f571: 48 89 e5mov%rsp,%rbp
> > 8110f574: 41 57
On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> 8110f570 :
> 8110f570: 55 push %rbp
> 8110f571: 48 89 e5mov%rsp,%rbp
> 8110f574: 41 57 push %r15
> 8110f576: 41 56
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Sedat Dilek wrote:
>> On 3/2/16, Steven Rostedt wrote:
>>>
>>> [ Resend with reply all, instead of just "reply" ]
>>>
>>> On Wed, 2 Mar 2016 16:53:36 +0100
>>> Sedat Dilek wrote:
>>>
8110f3f0 :
8110f3f0: 55
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Steven Rostedt wrote:
>>
>> [ Resend with reply all, instead of just "reply" ]
>>
>> On Wed, 2 Mar 2016 16:53:36 +0100
>> Sedat Dilek wrote:
>>
>>> 8110f3f0 :
>>> 8110f3f0: 55 push %rbp
>>> 8110f3f1: 48
[ Resend with reply all, instead of just "reply" ]
On Wed, 2 Mar 2016 16:53:36 +0100
Sedat Dilek wrote:
> 8110f3f0 :
> 8110f3f0: 55 push %rbp
> 8110f3f1: 48 89 e5mov%rsp,%rbp
> 8110f3f4: 41 57
On 3/2/16, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote:
>> >
>> > Right, most odd. Sedat, could you provide objdump -D of the relevant
>> > sections of vmlinux ?
>> >
>>
>> Can you give some clear instructions - for what shall I look for in
>> special?
>
> o
On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote:
> >
> > Right, most odd. Sedat, could you provide objdump -D of the relevant
> > sections of vmlinux ?
> >
>
> Can you give some clear instructions - for what shall I look for in special?
objdump -D vmlinux | awk '/<[^>]*>:$/ { p=0; } /
On 3/1/16, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote:
>> On Tue, 1 Mar 2016 11:05:42 +0100
>> Sedat Dilek wrote:
>>
>>
>> > [ FACT #3: TEST-CASE #2 ]
>> >
>> > The most reliable test-case is to simply unplug my external Logitech
>> > USB mouse - saw th
On 3/2/16, Jiri Kosina wrote:
> On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>
>> static bool start_flush_work(struct work_struct *work, struct wq_barrier
>> *barr)
>> {
>> struct worker *worker = NULL;
>> struct worker_pool *pool;
>> struct pool_workqueue *pwq;
>>
>> mi
On Wed, 2 Mar 2016, Sedat Dilek wrote:
>
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr)
> {
> struct worker *worker = NULL;
> struct worker_pool *pool;
> struct pool_workqueue *pwq;
>
> might_sleep();
>
> local_irq_dis
On 3/2/16, Sedat Dilek wrote:
> On 3/1/16, Alan Stern wrote:
>> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>>
>>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
>>> wrote:
>>> > On Sat, 3 Oct 2015 12:05:42 +0200
>>> > Sedat Dilek wrote:
>>> >
>>> >> So, at the beginning... dunno WTF is causing the
On 3/1/16, Alan Stern wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG
On 3/1/16, Alan Stern wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG
On Tue, 1 Mar 2016, Sedat Dilek wrote:
> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt wrote:
> > On Sat, 3 Oct 2015 12:05:42 +0200
> > Sedat Dilek wrote:
> >
> >> So, at the beginning... dunno WTF is causing the problems - no
> >> workaround for CLANG.
> >
> > Probably need to compile with gc
On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote:
> On Tue, 1 Mar 2016 11:05:42 +0100
> Sedat Dilek wrote:
>
>
> > [ FACT #3: TEST-CASE #2 ]
> >
> > The most reliable test-case is to simply unplug my external Logitech
> > USB mouse - saw this by accident.
> > YES, it was so simple
On Tue, 1 Mar 2016 11:05:42 +0100
Sedat Dilek wrote:
> [ FACT #3: TEST-CASE #2 ]
>
> The most reliable test-case is to simply unplug my external Logitech
> USB mouse - saw this by accident.
> YES, it was so simple.
Just to clarify, this happens on gcc and clang?
>
> --- dmesg_4.5.0-rc6-2-ll
45 matches
Mail list logo