On Mon, Apr 14, 2014 at 4:22 PM, Masami Hiramatsu
wrote:
> (2014/04/11 21:23), Denys Vlasenko wrote:
>> On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
>> wrote:
>>> At least, if we can trust Intel SDM, it says that depends
>>> on the operand-size (insn->opnd_bytes) and stack segment
>>> descri
(2014/04/11 21:23), Denys Vlasenko wrote:
> On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
> wrote:
>> At least, if we can trust Intel SDM, it says that depends
>> on the operand-size (insn->opnd_bytes) and stack segment
>> descriptor. Please check the SDM vol.1 6.2.2 Stack Alignment
>> and vol
(2014/04/14 21:24), Denys Vlasenko wrote:
> On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
> wrote:
>>> You can check whether insn had any prefix by checking
>>> insn->prefixes->nbytes != 0...
>>
>> No, since there are other prefixes (and it may be meaningless)
>> you should find 0x66 in insn->
On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
wrote:
>> You can check whether insn had any prefix by checking
>> insn->prefixes->nbytes != 0...
>
> No, since there are other prefixes (and it may be meaningless)
> you should find 0x66 in insn->prefixes->bytes[].
What "no"? Is my statement not
(2014/04/11 2:02), Denys Vlasenko wrote:
>> The (f64) modifier in x86-opcode-map.txt means that inat_is_force64()
>> is true for call opcode. So we won't reach "case 2:" in __get_immv32():
>> insn_get_prefixes() did set insn->opnd_bytes to 2 when it saw 0x66 prefix,
>> but it was before we reach t
On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
wrote:
> At least, if we can trust Intel SDM, it says that depends
> on the operand-size (insn->opnd_bytes) and stack segment
> descriptor. Please check the SDM vol.1 6.2.2 Stack Alignment
> and vol.2a, 3.2 Instructions (A-M), CALL--Call Procedure.
(2014/04/10 23:20), Denys Vlasenko wrote:
> On 04/10/2014 03:57 PM, Masami Hiramatsu wrote:
>> (2014/04/10 22:41), Denys Vlasenko wrote:
>>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
On 04/08, Jim Keniston wrote:
>
> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
>> 0xe
(2014/04/11 2:00), Oleg Nesterov wrote:
> On 04/10, Oleg Nesterov wrote:
>>
>> On 04/10, Masami Hiramatsu wrote:
>>>
>>> (2014/04/10 22:41), Denys Vlasenko wrote:
There is this monstrosity, "16-bit override for branches" in 64-mode:
66 e8 nn nn callw
Nobody sane us
(2014/04/10 23:28), Oleg Nesterov wrote:
> On 04/10, Masami Hiramatsu wrote:
>>
>> (2014/04/10 22:41), Denys Vlasenko wrote:
>>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
On 04/08, Jim Keniston wrote:
>
> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
>> 0xe8. Anything
On 04/10, Oleg Nesterov wrote:
>
> On 04/10, Masami Hiramatsu wrote:
> >
> > (2014/04/10 22:41), Denys Vlasenko wrote:
> > > There is this monstrosity, "16-bit override for branches" in 64-mode:
> > >
> > > 66 e8 nn nn callw
> > >
> > > Nobody sane uses it because it truncates instruction
On Thursday 10 April 2014 16:30, Denys Vlasenko wrote:
> On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
> > On 04/10, Denys Vlasenko wrote:
> >>
> >> There is this monstrosity, "16-bit override for branches" in 64-mode:
> >>
> >> 66 e8 nn nn callw
> >>
> >> Nobody sane uses it because it tru
On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
> On 04/10, Denys Vlasenko wrote:
>>
>> There is this monstrosity, "16-bit override for branches" in 64-mode:
>>
>> 66 e8 nn nn callw
>>
>> Nobody sane uses it because it truncates instruction pointer.
>>
>> Or rather, *I think* it should trunca
On 04/10, Masami Hiramatsu wrote:
>
> (2014/04/10 22:41), Denys Vlasenko wrote:
> > On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
> >> On 04/08, Jim Keniston wrote:
> >>>
> >>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
> >>>
> >>> No, I think e8 is the only
On 04/10/2014 03:57 PM, Masami Hiramatsu wrote:
> (2014/04/10 22:41), Denys Vlasenko wrote:
>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
>>> On 04/08, Jim Keniston wrote:
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
No, I think e8 is the
On 04/10, Denys Vlasenko wrote:
>
> There is this monstrosity, "16-bit override for branches" in 64-mode:
>
> 66 e8 nn nn callw
>
> Nobody sane uses it because it truncates instruction pointer.
>
> Or rather, *I think* it should truncate it (i.e. zero-extend to full width),
> but conceivab
(2014/04/10 22:41), Denys Vlasenko wrote:
> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
>> On 04/08, Jim Keniston wrote:
>>>
>>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
0xe8. Anything else?
>>>
>>> No, I think e8 is the only call instruction uprobes will see.
>>
>> Good.
>
>
On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
> On 04/08, Jim Keniston wrote:
>>
>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
>>> 0xe8. Anything else?
>>
>> No, I think e8 is the only call instruction uprobes will see.
>
> Good.
There is this monstrosity, "16-bit override for branche
On Wed, 2014-04-09 at 14:25 -0700, Jim Keniston wrote:
> On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> > On 04/08, Jim Keniston wrote:
> > >
> > > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > > 0xe8. Anything else?
>
> Oleg, thanks for responding to (if not necessarily
On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> On 04/08, Jim Keniston wrote:
> >
> > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > 0xe8. Anything else?
Oleg, thanks for responding to (if not necessarily agreeing with) all my
suggestions. I think your code is solid, but
On 04/08, Jim Keniston wrote:
>
> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > 0xe8. Anything else?
>
> No, I think e8 is the only call instruction uprobes will see.
Good.
> The following couple of paragraphs should be included in the code,
> perhaps merged with some of the related
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
No, I think e8 is the only call instruction uprobes will see.
>
The following couple of paragraphs should be included in the code,
perhaps merged with some of the related comments already there. Without
it, the code
21 matches
Mail list logo
