From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19014 invoked by alias); 10 Feb 2011 21:14:19 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 19001 invoked by uid 22791); 10 Feb 2011 21:14:18 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov X-Fcc: ~/Mail/utrace Cc: Jan Kratochvil , Project Archer Subject: Re: hw_breakpoint userland interface In-Reply-To: Oleg Nesterov's message of Thursday, 10 February 2011 21:55:43 +0100 <20110210205543.GA4590@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110207211129.GA23277@host1.dyn.jankratochvil.net> <20110208015844.B994A1814A4@magilla.sf.frob.com> <20110208205953.GA15932@redhat.com> <20110208231846.EC8BA1814AA@magilla.sf.frob.com> <20110210205543.GA4590@redhat.com> Message-Id: <20110210211412.3A1151806E0@magilla.sf.frob.com> Date: Thu, 10 Feb 2011 21:14:00 -0000 X-SW-Source: 2011-q1/txt/msg00042.txt.bz2 > Yes. Firstly we need to know what would be more convenient for those > who will actually use the new interface. Indeed. > Do you have any plans to introduce something like per-process > breakpoints, or (apart from inheriting) everything continues to > be per-thread? I think we should look at doing what makes most sense for the users, i.e. GDB. It's my impression that what is really desired is both options. In fact, I'm not altogether sure that anyone wants per-thread watchpoints at all, that being data watchpoints. When the issue is finding how some memory gets touched, then it doesn't make much sense to confine it to a particular thread--you want to know when the memory changed, whatever thread did it. If the hw_breakpoint interfaces also support (or will support) the hardware-assisted code breakpoints, then there it is probably desired to have thread-specific breakpoint support. But it's not clear to me that serious userland users like GDB would really make use of any hardware-based code breakpoints any time soon. They are so limited that you always need to fall back to traditional text-inserted breakpoints and I'm not sure it's deemed worthwhile to put effort into hardware-based code breakpoints for the small number of cases they can address. Thanks, Roland