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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250954 --- Comment #13 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Micha=C5=82 G=C3=B3rny from comment #12) I believe the intended use of PT_SETDBREGS in combination with the new thre= ad 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 t= he 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 th= at we already know that all hardware state is copied as needed. Would we repo= rt TDB_BORN before copying, it means that copying should occur under process l= ock 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 c= omes from the running thread, not from the embryo. So it really need be yet ano= ther event to not break API. --=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-8FuGDI6evc>