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 tp maintain if I get rid of the /proc stuff. (Plus, I couldn't > find any existing examples of anyone doing ioctl() to a /proc entry and I > kinda had to invent the method myself. It works fine, but that may just > be because I haven't found the right way to break it yet.)
I'm curious, how can this be? The worst case I can see is two syscalls instead of one, but that's not a lot higher. You can use pread/pwrite to avoid having to seek; it's only an issue when you have a structured request with a detailed reply. >> Side note: every time someone talks about a ptrace replacement I >> suggest stealing one from Solaris :-) It seems one of the areas that >> Sun thought out properly, although in my limited brushes with it in >> the last year I'm becoming less convinced of that. >> > > > What's Solaris ptrace() do that Linux ptrace() doesn't? Nothing says I > can't at least hack at putting it in. Solaris's debug interface is based in proc. No ioctl; you write structured requests to specific files, instead. http://docs.sun.com/app/docs/doc/816-5174/proc-4?l=en&a=view Its biggest advantage, in my experience so far, is that it is not entwined with wait and signals. Being attached doesn't mess up the debuggee's signals or its parent's wait behavior the way ptrace does. -- Daniel Jacobowitz CodeSourcery
