Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: writing on the text segment
Message-ID: <10376@mimsy.UUCP>
Date: 29 Jan 88 09:25:50 GMT
References: <11476@brl-adm.ARPA> <207@sdti.UUCP> <2624@bloom-beacon.MIT.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 25

>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