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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250954 --- 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-thread ? 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) created after it makes those modifications, makes the whole concept of inheriting debug 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 different in Linux, or exists in Linux as well. It is between the event from 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 lldb 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 have 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 fully set up. It might be an interesting experiment... -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-250954-227-VwDm8tWsyf>