On 07/12/16 13:14, Jan Beulich wrote:
On 07.12.16 at 14:05, wrote:
>> On 07/12/16 08:22, Jan Beulich wrote:
>> On 06.12.16 at 17:49, wrote:
On 06/12/16 11:13, Jan Beulich wrote:
> @@ -2359,7 +2360,7 @@ x86_decode(
> }
> }
>
> -if ( override_se
>>> On 07.12.16 at 14:05, wrote:
> On 07/12/16 08:22, Jan Beulich wrote:
> On 06.12.16 at 17:49, wrote:
>>> On 06/12/16 11:13, Jan Beulich wrote:
@@ -2359,7 +2360,7 @@ x86_decode(
}
}
-if ( override_seg != -1 && ea.type == OP_MEM )
+if ( o
On 07/12/16 08:22, Jan Beulich wrote:
On 06.12.16 at 17:49, wrote:
>> On 06/12/16 11:13, Jan Beulich wrote:
>>> @@ -2359,7 +2360,7 @@ x86_decode(
>>> }
>>> }
>>>
>>> -if ( override_seg != -1 && ea.type == OP_MEM )
>>> +if ( override_seg != x86_seg_none )
>>> e
>>> On 06.12.16 at 17:49, wrote:
> On 06/12/16 11:13, Jan Beulich wrote:
>> @@ -2359,7 +2360,7 @@ x86_decode(
>> }
>> }
>>
>> -if ( override_seg != -1 && ea.type == OP_MEM )
>> +if ( override_seg != x86_seg_none )
>> ea.mem.seg = override_seg;
>
> Could we get awa
On 06/12/16 11:13, Jan Beulich wrote:
> @@ -2359,7 +2360,7 @@ x86_decode(
> }
> }
>
> -if ( override_seg != -1 && ea.type == OP_MEM )
> +if ( override_seg != x86_seg_none )
> ea.mem.seg = override_seg;
Could we get away with asserting ea.type == OP_MEM if override_
Especially for x86_insn_operand_ea() to return dependable segment
information even when the caller didn't consider applicability, we
shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
and set it to OP_MEM when we actually encounter memory like operands.
This requires to eliminate
