Date: Mon, 09 Nov 2020 18:56:37 +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-8FuGDI6evc@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 #13 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Michał Górny from comment #12) I believe the intended use of PT_SETDBREGS in combination with the new thread tracking is to set debug registers to desired configuration on each PL_FLAG_BORN event. This should be most straight-forward. WRT to the race itself, trying to close it would affect normal operation of thread creation, as opposed to just causing minor inconvenience to the ptrace(2) consumers. We create thread, including the setup of all machine state, then we fire it running, up to the point of running at trampoline returning to the user space. This moment is when we report TBD_BORN to ptracestop(). It is important to do that stop from the context of the running new thread, so that we already know that all hardware state is copied as needed. Would we report TDB_BORN before copying, it means that copying should occur under process lock to guarantee consistency with potential modifications from debuggers, and we do not want this. Also I think existing consumers of TDB_BORN already expect that the event comes from the running thread, not from the embryo. So it really need be yet another event to not break API. -- 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-8FuGDI6evc>