Date: Wed, 11 Nov 2020 09:53:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 250954] ptrace(): weird ordering between inheriting debug registers and reporting a new thread Message-ID: <bug-250954-227-VwDm8tWsyf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-250954-227@https.bugs.freebsd.org/bugzilla/> References: <bug-250954-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250954 --- Comment #17 from Pavel Labath <p-freebsd@labath.sk> --- (In reply to Konstantin Belousov from comment #16) > Do you mean that events channel for Linux debugging facility is per-threa= d ? Yes, the linux ptrace interface deals with individual threads, essentially.= It even allows funny things like tracing a subset of the threads of a process, tracing different threads by different processes, etc. At first, I've found this setup strange, but now that I see the effort other kernels need to go to in order to present a sequentially consistent view of events that are inherently unsequenced, I am beginning to think that was the right decision after all. But I digress... > As result, we do not really need pre-notification about new thread to be = created. It's true that this event is not as critical here as in the linux case. However, the fact that the debugger cannot know whether its modification of= the debug registers will be reflected in the threads that are (supposedly) crea= ted after it makes those modifications, makes the whole concept of inheriting d= ebug registers pretty useless, imo. That said, it probably doesn't make sense to change overall design because = of this issue, as the workaround is pretty straight-forward. > I suspect that the race that we discussed there either handled somewhat d= ifferent in Linux, or exists in Linux as well. It is between the event fro= m the context of the new thread, and kernel taking snapshot of the state of= the parent thread to set child state. I am not completely sure what happens inside the kernel, but the way that l= ldb uses this interface (it forces a synchronization by waiting for both events, before doing anything else) means that the race (if it exists) does not hav= e a chance to surface. I don't know what would happen if we actually tried to quickly start messing with the parent thread before the child thread is ful= ly set up. It might be an interesting experiment... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-250954-227-VwDm8tWsyf>