On Tue, 2008-06-24 at 22:49 -0400, Chris Moller wrote:
Comments, up to and including What the hell are you smoking? welcome.
I'd rather phrase this as what are we not getting out of ptrace that we
really want. Answering that will frame how we go about getting it. (I
admit to not having looked
On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote:
Extending ptrace seems like a sad idea. If Linux is going to grow a
new userspace-accessible debug interface, can't it go in /proc or
something?
Actually, that's exactly what utracer does. It's a module that creates
an
Phil Muldoon wrote:
Chris Moller wrote:
Due to a complete lack of interest, I'm shelving utracer. May it
collect dust in peace.
I was (and still am) interested in it from a direct api point of view.
As a an end-tool not so much.
Systemtap is cool, and, based on tinkering with it for
Daniel Jacobowitz wrote:
On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote:
Extending ptrace seems like a sad idea. If Linux is going to grow a
new userspace-accessible debug interface, can't it go in /proc or
something?
Actually, that's exactly what utracer does.
On Wed, Jun 25, 2008 at 04:11:50PM -0400, Chris Moller wrote:
The main reason I'm moving away from this approach is that the overhead
of read()/write()/ioctl() to/from a /proc pseudo-entry is a lot higher
than a simple syscall. It's mostly a performance thing, but there's also
less code
From: Daniel Jacobowitz [EMAIL PROTECTED]
Date: Wed, 25 Jun 2008 11:38:25 -0400
The single biggest pain in GDB's process management is dealing with
signals, especially the ways that ptrace interferes with normal
operation.
Because of this, and other similar examples, I believe the only
way to
David Miller wrote:
From: Daniel Jacobowitz [EMAIL PROTECTED]
Date: Wed, 25 Jun 2008 11:38:25 -0400
The single biggest pain in GDB's process management is dealing with
signals, especially the ways that ptrace interferes with normal
operation.
Because of this, and other similar
