From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28601 invoked by alias); 30 Apr 2009 17:04:25 -0000 Received: (qmail 28400 invoked by uid 22791); 30 Apr 2009 17:04:22 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Apr 2009 17:04:14 +0000 Received: (qmail 32220 invoked from network); 30 Apr 2009 17:04:12 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Apr 2009 17:04:12 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] watchthreads2.exp: gdb can drop watchpoints Date: Thu, 30 Apr 2009 17:04:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans References: <20090429231844.609AC84890@localhost> In-Reply-To: <20090429231844.609AC84890@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904301804.24014.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00813.txt.bz2 On Thursday 30 April 2009 00:18:44, Doug Evans wrote: > Hi. > > I wrote this testcase to help exercise h/w watchpoints in linux gdbserver. > [A patch I'm working on, based on Pierre's win32 patch.] > > Running it with just gdb periodically fails. > I traced this to gdb dropping watchpoints if, for example, > an shlib breakpoint from a different thread happens at the same time > (e.g. one happens and then while gdb is stopping the remaining threads > the other happens?). Yes, I've seen this before. > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0xf7ff3101 > infrun: stopped by watchpoint > infrun: stopped data address = 0x8049af8 > infrun: context switch > infrun: Switching context from Thread 0xf6563bb0 (LWP 22743) to Thread 0xf6db4bb0 (LWP 22742) > infrun: BPSTAT_WHAT_CHECK_SHLIBS > infrun: no stepping, continue There are two issues here. - If new shared libraries are loaded, it looks like update_watchpoint will just forget about the old value of the watchpoint. - BPSTAT_WHAT_CHECK_SHLIBS handling. I was just mentioning something related yesterday. In your case, it goes something like this: Before deciding that the stop bpstat's main action should be BPSTAT_WHAT_CHECK_SHLIBS, bpstat_stop_status iterated over all watchpoints and updated all their values (see: bpstat_stop_status -> bpstat_check_watchpoint -> watchpoint_check). Even if a watchpoint hit happens at the same time that a shlib is handled, GDB gives priority to the shlib event, and immediately resumes the inferior. linux-nat.c will hold the watchpoint hit pending, and will still report it afterwards, but, by the time that pending event is handled, the watchpoint value had already been updated, and will look like it didn't change, so GDB ignores the stop. You'll see this much easier if you enable 'set debug lin-lwp 1' in addition to 'set debug infun'. See also the current "Do not call read_pc in startup_inferior" discussion. On Thursday 30 April 2009 00:18:44, Doug Evans wrote: > I don't know if you want to wait until the bug is fixed before this > testcase can be checked in. I won't be able to look at the bug > for awhile but maybe someone else will, so I'm submitting this testcase. > It (periodically) fails on i386-linux, amd64-linux (depending on > how the o/s happened to schedule the threads of course). Please don't add failing tests to the testsuite (on purpose, that is :-) ). The procedure is to open a PR, and make the test kfail instead of failing. I see you've already opened a PR, so the test is OK if you make that change. Thanks. -- Pedro Alves