Date: Mon, 09 Nov 2020 12:59:05 +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-NHG7iSXNVQ@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 #12 from Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> --- Watchpoints are global in LLDB. If user sets a watchpoint, he expects it to apply to all threads, existing and new. To achieve LLDB does the following: 1. When watchpoint is being set, it sets debug registers on all threads it knows of. 2. When a new thread is created, it assumes it inherited debug registers fr= om the previous thread. The problem is that there is a window when the new thread is created already but it is not reported to LLDB yet. During this window, changes to debug registers do not apply to the new thread because LLDB does not know about i= t. Firstly, I'm asking whether this is better worked around by having LLDB rec= heck the thread list on every stop (i.e. assume that LWP events are unreliable) = or by having it explicitly set dbregs on every new thread (i.e. assuming that dbreg inheritance is unreliable). Secondly, I believe this behavior is suboptimal. If the kernel is 1) repor= ting new threads, and 2) making them inherit dbregs from parent, it would be reasonable to do it in a way that would permit programs to actually rely on that and not have to reimplement either of the two functions. --=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-NHG7iSXNVQ>