Hi,
Thank you for your advice.
And I find a good book there's one chapter describing the implementation of
ptrace.
But it was written in Chinese, not English.It's name is  <LINUX内核源代码情景分析>
There's no English version right now.
I plan to read it first and if there's some problems, I will post in this
mail list.


On Tue, Nov 4, 2008 at 1:51 AM, Mulyadi Santosa
<[EMAIL PROTECTED]>wrote:

> Hi...
>
> On Mon, Nov 3, 2008 at 11:24 PM, Steven Zhou <[EMAIL PROTECTED]>
> wrote:
> > Dear all,
> >
> > Recently, I studied the process structure "task_struct", and there's a
> > member "ptrace" confused me.
> > I have studied how to use  ptrace system call first, and I have done.
> >
> > But I'm also confused with the principle of system call sys_ptrace()
> > implementation. I tried google it,
> > but I'm not satisfied with the result. A good article "playing with
> ptrace"
> > is fit for using ptrace, but it does
> > not explain how the ptrace() was implemented by kernel.
> >
> > Is there any one have the article about the implementation of ptrace()?
> > Can you share it ?
>
> I think better to grab book  like Understanding the Linux kernel 3rd
> edition...because ptrace implementation covers signals handling,
> return from syscall, sometimes single stepping and so on.
>
> But in essence, there aren several modes of ptracing:
> 1. single stepping. this is done by enabling debug flag (if I remember
> correctly) or replacing next instruction with INT 0x3h
>
> 2. trapping syscall. this is done by setting a flag so that everytime
> there is a transition into kernel space(by calling syscall) or
> returning from syscall (ret_from_syscall...see entry.S), a
> notification is sent to ptracer. This also mean rescheduling is
> done...mean while the traced process is temporarily "halted" so its
> state can be analyzed by the tracer.
>
> regards,
>
> Mulyadi.
>



-- 
Best Regards.

Reply via email to