Date: Tue, 07 Feb 2012 11:12:11 +0800 From: David Xu <listlog2011@gmail.com> To: freebsd-current@freebsd.org Subject: Re: [ptrace] please review follow fork/exec changes Message-ID: <4F30968B.5060101@gmail.com> In-Reply-To: <4F2094B4.70707@juniper.net> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012/1/26 7:48, Dmitry Mikulin wrote: > <snip> > The debugger needs to intercept fork() in both parent and child so it > can detach from the old process and attach to the new one. Maybe it'll > make more sense in the context of gdb changes. Should I send them too? > Don't think Marcel included that patch... > >> >> 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. > > Yes, the debugger gets SIGTRAPs. The problem arises when the real > parent of the forked process has the code to collect termination > status. Since attaching to a process changes the parent/child > relationships, we need to keep track of the children lost due to > re-parenting so we can properly attribute their exit status to the > "real" parent. > I recall that someone brought a topic in the list said that this should be fixed, debugging a process should not change parent-child relation, instead a new link list data structure should be added to struct proc to trace debugged process, this will make code clean with a small memory overhead. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F30968B.5060101>