Date: Mon, 09 Nov 2020 12:29: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-sY1ieI9PPN@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 #10 from Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> --- Hmm, I should have mentioned that this affect LLDB right now. The scenario where this happens is this: 1. Create breakpoint immediately after pthread_create(). 2. When LLDB hits the breakpoint, create a watchpoint. 3. Resume. The problem is that the new thread is already created at 2. but LLDB does n= ot know about it, so the watchpoint is created only on thread 1. We can solve this on LLDB end in either of two ways: a. Relist all threads (via PT_GETLWPLIST) on every stop. In this case, LLD= B at point 2. would have the correct thread list even though the event is not yet delivered. b. Copy dbregs to new threads in LLDB when they are reported. In this case, the watchpoints are correctly propagated to new threads when LLDB becomes a= ware of these threads. Regardless of this, it would be nice if kernel had predictable behavior her= e, i.e. reported the new thread before pthread_create() returned. --=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-sY1ieI9PPN>