Hi,
I have been trying to understand the features supported by linux ptrace
interface. In Solaris I think ptrace was replaced by /proc interface and
they claim it better. Are there any plans to do the same thing in linux?
Thanks,
Pradeep Padala
Linux already posesses modular support for a /proc filesystem, every distribution, and I believe the stock kernel config includes support for this under the filesystems section by default.
On Thu, 20 Jun 2002 17:10:43 -0400 (EDT)
Pradeep Padala <[email protected]> wrote:
> Hi,
> I have been trying to understand the features supported by linux ptrace
> interface. In Solaris I think ptrace was replaced by /proc interface and
> they claim it better. Are there any plans to do the same thing in linux?
>
> Thanks,
> Pradeep Padala
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> Linux already posesses modular support for a /proc filesystem, every distribution, and I believe the stock kernel config includes support for this under the filesystems section by default.
I should have been clearer. I would like to know about the features ptrace
supports like "system call tracing", "setting breakpoints" etc.
Traditionally they were done through ptrace interface. In solaris and I
guess in other operating systems like IRIX, they are moved to /proc
interface. Applications wanting to trace programs like gdb, would use
ioctl on the /proc/<pid> and trace the programs.
As far as I could investigate, I didn't find any such interface in linux.
Programs like strace do the tracing through ptrace only.
Please let me know if you know more about this.
--pradeep
On Thu, 2002-06-20 at 14:46, Pradeep Padala wrote:
> As far as I could investigate, I didn't find any such interface in linux.
> Programs like strace do the tracing through ptrace only.
>
> Please let me know if you know more about this.
There is no such interface in Linux and currently no plans to develop a
Solaris-style /proc.
Some work that may go into 2.5, task ornaments, may facilitate easier
debugging and perhaps make such a /proc more feasible in the future.
Robert Love
> There is no such interface in Linux and currently no plans to develop a
> Solaris-style /proc.
I would like to develop such interface. Is it Ok if I go ahead and send a
patch. I have been playing with ptrace in the kernel for a while.
> Some work that may go into 2.5, task ornaments, may facilitate easier
> debugging and perhaps make such a /proc more feasible in the future.
What are task ornaments? Can you elaborate on this?
TIA
--pradeep
Hi!
> > As far as I could investigate, I didn't find any such interface in linux.
> > Programs like strace do the tracing through ptrace only.
> >
> > Please let me know if you know more about this.
>
> There is no such interface in Linux and currently no plans to develop a
> Solaris-style /proc.
I believe such proc interface is wrong thing to do. ptrace() is really
very *very* special thing, and you don't want it hidden in some kind
of /proc magic.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Pavel Machek wrote:
>I believe such proc interface is wrong thing to do. ptrace() is really
>very *very* special thing, and you don't want it hidden in some kind
>of /proc magic.
Five years ago I believed all that mattered was the functionality:
whether it was exposed via ptrace() and signals or via /proc and ioctls
was irrelevant. Since then, having spent a lot of time using both Linux
ptrace() and Solaris /proc, I've learned that there is a huge difference
between the two. The Solaris implementation, via /proc, is very clean.
The Linux implementation, via ptrace(), is icky.
For example, ptrace() uses signals as part of its interface; this
is a gross kludgy hack, and it breaks various things. For instance,
overloading the meaning of signals causes wait4() to break in the traced
process, and you have to do all sorts of workarounds in the tracer
to make tracing transparent. Go read the source code to strace(1).
I think if you spend the time to understand it all, you'll agree with
me that it is sadly hairy stuff.
The Solaris /proc implementation, in contrast, was much cleaner,
in my experience. I suspect this is partially because the Solaris
implementation was more carefully thought-through, but also the interface
helped: by not overloading the meaning of signals, the Solaris /proc
interface avoids changing the semantics of signal-related functionality
in the traced process, and this makes for cleaner code.
Solaris /proc also had other nice features, like the ability to follow
fork() automatically and so on. (Check out what strace has to do with
ptrace(): it actually does binary code-rewriting of the traced process
on the fly to work around lack of functionality in ptrace().) Many of
these features, of course, were orthogonal to whether the process tracing
was implemented via ptrace() and signals or /proc and ioctls.
> The Solaris /proc implementation, in contrast, was much cleaner,
> in my experience. I suspect this is partially because the Solaris
> implementation was more carefully thought-through, but also the interface
> helped: by not overloading the meaning of signals, the Solaris /proc
> interface avoids changing the semantics of signal-related functionality
> in the traced process, and this makes for cleaner code.
I completely agree with you. Using ptrace to do user level extensions like
UFO(http://www.cs.ucsb.edu/projects/ufo/index.html) is grossly inefficient
and kludgy.
--pradeep
Hi!
> >I believe such proc interface is wrong thing to do. ptrace() is really
> >very *very* special thing, and you don't want it hidden in some kind
> >of /proc magic.
>
> Five years ago I believed all that mattered was the functionality:
> whether it was exposed via ptrace() and signals or via /proc and ioctls
> was irrelevant. Since then, having spent a lot of time using both Linux
> ptrace() and Solaris /proc, I've learned that there is a huge difference
> between the two. The Solaris implementation, via /proc, is very clean.
> The Linux implementation, via ptrace(), is icky.
>
> For example, ptrace() uses signals as part of its interface; this
> is a gross kludgy hack, and it breaks various things. For instance,
> overloading the meaning of signals causes wait4() to break in the traced
> process, and you have to do all sorts of workarounds in the tracer
> to make tracing transparent. Go read the source code to strace(1).
> I think if you spend the time to understand it all, you'll agree with
> me that it is sadly hairy stuff.
>
> The Solaris /proc implementation, in contrast, was much cleaner,
> in my experience. I suspect this is partially because the Solaris
> implementation was more carefully thought-through, but also the interface
> helped: by not overloading the meaning of signals, the Solaris /proc
> interface avoids changing the semantics of signal-related functionality
> in the traced process, and this makes for cleaner code.
>
> Solaris /proc also had other nice features, like the ability to follow
> fork() automatically and so on. (Check out what strace has to do with
> ptrace(): it actually does binary code-rewriting of the traced process
> on the fly to work around lack of functionality in ptrace().) Many of
> these features, of course, were orthogonal to whether the process tracing
> was implemented via ptrace() and signals or /proc and ioctls.
Agreed signals should not be overloaded.
I helped with subterfugue (.sf.net), so I know about this
issues. Using signals is ugly. I'm not sure what to do with following
fork; I do not think we want to bloat kernel with that (and I believe
we have helper [CLONE_? flag?] that allows us to do that too). I still
think ptrace() should have its own syscall. Its very special thing.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?