chris@mimsy.UUCP (Chris Torek) (01/29/88)
>In article <207@sdti.UUCP> mjy@sdti.UUCP (0000-Michael J. Young) writes: >>That's what the ptrace(2) system call is for. In article <2624@bloom-beacon.MIT.EDU> wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: >If you have a shared-text type of executable, you can't guarentee >ptrace-ability. If someone else is executing the same text, the system >is forced to deny you write-permission with the error 'text busy'. >(Otherwise the other process would also get hit with the breakpoints.) >The other process can still be corrupted however, if it is started >*after* you insert the breakpoints. Now it gets amusing, since you >can't *remove* the breakpoints once the other process is started. This last is simply a bug: the second process should get a new copy of the executable, since the first is being used for something else; i.e., a shared-text executable that is being traced should automatically become unshared. Too, ptrace is a horrible interface. Even so, there is no really good reason not to be able to ptrace or otherwise take over one of your own processes even if its text is already shared. The kernel should simply make an unshared copy for you to tweak. Only the adjusted sections should not be shared, at that---but doing *this* requires rewriting the VM code. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jum@cosmo.UUCP (Uwe Mager) (01/30/88)
In article <10376@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >This last is simply a bug: the second process should get a new copy >of the executable, since the first is being used for something >else; i.e., a shared-text executable that is being traced should >automatically become unshared. Too, ptrace is a horrible interface. At least in SVR3 they have fixed that I think. Regarding the ptrace stuff, in SVR3 there happen to be a lot of hooks for a /proc interface. Is there a file system availiable using that ? -- Jens-Uwe Mager jum@focus.UUCP || jum@cosmo.UUCP
rrg@sfsup.UUCP (R.R.Gomes) (02/02/88)
/proc (the process file system) for System V has existed within AT&T for several years and will likely be included in a future release of the system. In addition to the capabilities described in Tom Killian's USENIX paper several years ago it contains substantial improvements including selective system call interception and dissociation of the user interface from internal system details (such as the proc and user structures). The implementation is also more portable, and works over RFS (so that, for example, processes running on remote machines can be traced or debugged). Ron Gomes (attunix!rrg)