lkml.org 
[lkml]   [2008]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] x86: fix text_poke
Mathieu Desnoyers wrote:
>
>>> b) there might be a jump into the middle of this instruction sequence?
>>>
>> If we change that, as discussed above, so the liveliness of ZF and of
>> the %al register is still insured by leaving the mov and test
>> instructions in place, we end up only modifying a single instruction and
>> the problem fades away. We would end up changing a jne for a jmp.
>
> So, if we do is I propose here, we have to take into account this
> question too. Any jump that jumps in the middle of this instruction
> sequence would have to insure correct liveliness of %al and ZF. However,
> since we just limited the scope of their liveliness, there are no other
> code paths which can jump in the middle of our instruction sequence and
> insure correct ZF and %al liveliness.
>

I wanted to point out that this, in particular, is utter nonsense.
Consider a sequence that looks something like this:

if (foo ? bar : imv_cond(var)) {
blah();
}

An entirely sane transformation of this (as far as gcc is concerned), is
something like:

cmpl $0,foo
je 1f
cmpl $0,bar
jmp 2f
1:
#APP
movb var,%al /* This is your imv */
#NO_APP
testb %al,%al
2:
je 3f
call blah
3:

Your code would take the movb-testb-je sequence and combine them, then
we jump into the middle of the new instruction when jumping at 2!

There are only two ways to deal with this - extensive analysis of the
entire flow of control, or telling the compiler exactly what is
*actually* going on. The latter is the preferred way, obviously.

-hpa



\
 
 \ /
  Last update: 2008-04-25 21:29    [W:0.193 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site