e add marker or tracepoint to trace every syscalls,
we might have to put it in the tracehook or audit and set
TIF_SYSCALL_TRACE for every process, or put tracepoint
in the syscall entrance/exit asm-code and check another
flag. Since latter adds additional flag-checking in fast-path,
I think it is not
continue.) But this is how you'd do it sensibly
> with tracepoints IMHO. (The details I just described are not much different
> from what utrace global tracing would have for handling TIF_SYSCALL_TRACE.)
I agree that.
I think if I can set TIF_SYSCALL_TRACE on each process safely, it can
few.
> - Different subsystems are interested in different instruction
> attributes, and/or classify instructions differently.
> - Some subsystems are interested in only certain instructions.
> - Some subsystems, such as fault handlers, want to maximize efficiency
> by examining as little of the instruction as possible; while others,
> such as *probes, take a more leisurely approach (e.g., reading enough
> bytes to capture the largest possible instruction, even if that means
> faulting in a page).
>
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
ch as *probes, take a more leisurely approach (e.g., reading enough
> bytes to capture the largest possible instruction, even if that means
> faulting in a page).
Indeed. I think those efficiency-required subsystems are so arch-dependent
that we can (just) shares instruction bitmaps or provi
Jim Keniston wrote:
> On Fri, 2009-02-06 at 15:49 -0500, Masami Hiramatsu wrote:
>> Hi Jim,
>>
>> I'm also interested in the instruction decoder.
>> If you don't mind, could we share the API specification?
>> I'd like to port djprobe on it.
>
ly, I'm developing insn_get_length() based on your prototype and
porting djprobe on it. After tested code, I'd like to post the insn_x86 code.
Thank you,
>
> Thanks.
> Jim
>
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
Jim Keniston wrote:
> On Tue, 2009-02-10 at 10:12 +0530, Ananth N Mavinakayanahalli wrote:
>> On Mon, Feb 09, 2009 at 06:05:56PM -0500, Masami Hiramatsu wrote:
>>> Jim Keniston wrote:
>>>> On Fri, 2009-02-06 at 15:49 -0500, Masami Hiramatsu wrote:
>>>>&g
Hi Jim,
Jim Keniston wrote:
> On Fri, 2009-02-27 at 16:20 -0500, Masami Hiramatsu wrote:
> ...
>> Here are a patch against your code and an example code for
>> instruction length decoder.
>> Curiously, KVM's instruction decoder does not completely
>> cover al
Hi Jim and Sriker,
Here, I almost rewrote my patch.
Changelog:
- rewrite decoding logic based on Intel' manual.
- supoort insn_get_sib(),insn_get_displacement()
and insn_get_immediate() too.
- support 3 bytes opcode and 64bit immediate.
- introduce some bitmaps.
Thank you,
Masami Hira
Hi Jim,
Jim Keniston wrote:
> Quoting Masami Hiramatsu :
>
>> Hi Jim and Sriker,
>>
>> Here, I almost rewrote my patch.
>>
>> Changelog:
>> - rewrite decoding logic based on Intel' manual.
>> - supoort insn_get_sib(),insn_get_displacement()
&g
think we need some symbol information for supporting
return probes in user space. Could you tell me how to work it?
is that requires some user-space helper?
> - Support for Other Architectures.
> - Jump optimization.
I assume that you meant this is "uprobe-booster" to skip
just sin
could merge it or
> something like it.
So, could you tell us how the task-finder works and is implemented?
I think we'd better clarify what functions are required for uprobes
and pmu, and I think we may be able to re-implement improved pmu
on utrace.
Thank you,
--
Masami Hirama
? :-)
> Layering this dynamic
> capability seems like the natural way to go, and is easily done with
> utrace and/or tracepoints.
Sure, and I think that will allow us to use uprobe events as
trace-events, because we can set probes before executing programs. :-)
Thank you!
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
e time to limit the function tracer to a specific app.
>
> #!/bin/sh
> echo $$ > /debug/tracing/set_ftrace_pid
> echo function > /debug/tracing/current_tracer
> exec $*
I recommend you to add below line at the end of the script,
from my experience. :)
echo nop > /debug/tracing/cur
Masami Hiramatsu wrote:
> Steven Rostedt wrote:
>> On Tue, 2010-01-12 at 05:54 +0100, Frederic Weisbecker wrote:
>>
>>> Now what if I want to launch ls and want to profile a function
>>> inside. What can I do with a trace event. I can't create the
>>>
ent x86 decoder doesn't support FP(x87) instructions.(even
it already supported AVX) But I think it's not so hard to add it.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
Jim Keniston wrote:
> On Mon, 2010-01-18 at 10:58 -0500, Masami Hiramatsu wrote:
>> Jim Keniston wrote:
>>> Not really. For #3 (boosting), you need to know everything for #2,
>>> plus be able to compute the length of each instruction -- which we can
>>
in kernel,
we need to jump into kernel space anyway. "Booster" (just skips
a single-stepping(trap) exception) may be useful for
improving uprobe performance.
And also as Andi said, using jump instead of int3 in userspace
has 2GB address space limitation. It's not a problem for kernel
i
ad can only have a single trap at any one time that should be
> enough.
Hmm, it is a good idea. Well, we'll have a copy of original insn
in kernel, but it could be simpler than managing XOL vma. :-)
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
e it enough generic, we don't need XOL code. However, it is
hard and takes a time to make it so generic, and can be slower than
XOL on some complex instructions (and also, how many instructions
should be supported is enough for that?). Indeed, I must admit that
implementing an emulator should be exciting for kernel hackers :)
Anyway, if you think we can't avoid generalizing x86 emulators
(even without uprobes), maybe, it a good way to go.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhira...@redhat.com
20 matches
Mail list logo
