On Monday, February 06, 2012 10:12:11 pm David Xu wrote: > 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.
Yes, I have some old patches to start on this, but I hadn't really finished them, and it makes wait() a bit more complicated. It would be nice if ptrace() had its own pwait() or some such instead of overloading wait(). -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
