Date: Wed, 25 Jan 2012 09:48:24 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <marcelm@juniper.net> Cc: freebsd-current Current <freebsd-current@freebsd.org>, Dmitry Mikulin <dmitrym@juniper.net> Subject: Re: [ptrace] please review follow fork/exec changes Message-ID: <20120125074824.GD2726@deviant.kiev.zoral.com.ua> In-Reply-To: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 01:36:55PM -0800, Marcel Moolenaar wrote: > All, >=20 > Please review the attached changes (done by Dmitry -- CC'd) to add suppor= t for > PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK. >=20 > I'll commit this when there are no comments/objections. > Thanks, I would certainly appreciate some more words describing the changes. What is the goal of introducing the PT_FOLLOW_EXEC ? To not force the debugger to filter all syscall exits to see exec events ? Why did you moved the stopevent/ptracestop for exec events from syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC is not removed from syscallret() ? I do not think that TDB_EXEC can be seen there after the patch. The same question about TDB_FORK. If possible, I would greatly prefer to have fork changes separated. I doubt that disallowing RFMEM while tracing is the right change. It may be to fix some (undescribed) bug, but RFMEM is documented behaviour used not only for vfork(2), and the change just breaks rfork(2) for debugged processes. Even vfork() should not be broken, since I believe there are programs that rely on the vfork() model, in particular, C shell. It will be broken if vfork() is substituted by fork(). The fact that it breaks only under debugger will make it esp. confusing. Why do we need to have TDB_FORK set for td2 ? Does the orphan list change intended to not lost the child after fork ? But the child shall be traced, so debugger would get the SIGTRAP on the attach on fork returning to usermode. I remember that I explicitely tested this when adding followfork changes. --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8fs8gACgkQC3+MBN1Mb4iV5wCgzqH0Lf3OWLNVKFnebVoXiLqn 1dMAnjkLw03Q6x/DarX4KxiaXBTyiefI =0ixd -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120125074824.GD2726>