From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19973 invoked by alias); 10 May 2010 21:33:05 -0000 Received: (qmail 19961 invoked by uid 22791); 10 May 2010 21:33:04 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT,TW_OC X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 May 2010 21:32:57 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4ALWUp2090226 ; Mon, 10 May 2010 23:32:30 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms3.u-strasbg.fr [IPv6:2001:660:2402:d::12]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o4ALWUJD041683 ; Mon, 10 May 2010 23:32:30 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4ALWToq084403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 10 May 2010 23:32:29 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" , "'Joel Brobecker'" Cc: References: <006601cae54b$368452f0$a38cf8d0$@muller@ics-cnrs.unistra.fr> <201005081823.56505.pedro@codesourcery.com> <004e01caf010$ac780450$05680cf0$@muller@ics-cnrs.unistra.fr> <201005102027.10080.pedro@codesourcery.com> In-Reply-To: <201005102027.10080.pedro@codesourcery.com> Subject: RE: [RFC] Add watchpoint hit address function to procfs.c Date: Mon, 10 May 2010 21:33:00 -0000 Message-ID: <001801caf088$4d8a7ae0$e89f70a0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: 2010-05/txt/msg00234.txt.bz2 > See here for a workaround that requires no testsuite changes: > Yes, but that one requires root privileges... I will try to resubmit my lib/gdb.exp patch shortly... > > So there are no regressions. > > Thanks. > > > Remaining failures are: > > pierre@fpcOpenSolaris:~/gdbcvs/build64/gdb/testsuite$ grep FAIL > gdbv4.sum > > FAIL: gdb.base/watch-read.exp: read watchpoint triggers when value > doesn't change, trapping reads and writes > > FAIL: gdb.base/watch-read.exp: only read watchpoint triggers when > value doesn't change > > Odd. I don't suppose a procfs client is supposed to > handle overlapping watchpoints instead of having the kernel > handle them? The test explicitly sets a write watchpoint watching > the same memory as a read watchpoint, and expects reads to still > be trapped. Maybe the write request overwrote the read > request? Maybe this is a kernel bug? No idea here, the log inspection clearly confirms that the read watch after watch insertion is missed. > > KFAIL: gdb.threads/watchthreads2.exp: gdb can drop watchpoints in > > multithreaded > > app (PRMS: gdb/10116) > > FAIL: gdb.threads/watchthreads.exp: threaded watch loop > > FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit > > FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit > > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in > thread > > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in > thread > > FAIL: gdb.threads/watchthreads.exp: combination of threaded > watchpoints = 30 Those failure are a problem within the watchthreads.exp source, the test uses '\r' patterns without the '\n' as is usual... If I replace all '\r' by '\r+' then there are no failures left for that test. I ran again both versions (with TIDGET or plain zero) and got exactly the same output for both. Thus, apparently the thread number is not necessary to get the location of the watchpoint even if it is not in the main thread (for my OpenSolaris version at least...) It is rather unusual to use \r patterns alone inside the GDB testsuite... The following patch fixes the failures shown here, is this patch OK, or should I replace all '\r' into '\r\n' (in that case, my lib/gdb.exp patch would catch it...) Pierre testsuite ChangeLog entry: 2010-05-10 Pierre Muller * gdb.threads/watchthreads.exp: Allow multiple `\r' in regular expression pattern to avoid problems with systems uses `Dos-like' newlines. Index: watchthreads.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/watchthreads.exp,v retrieving revision 1.11 diff -u -p -r1.11 watchthreads.exp --- watchthreads.exp 5 May 2010 18:07:03 -0000 1.11 +++ watchthreads.exp 10 May 2010 21:12:44 -0000 @@ -79,11 +79,11 @@ for {set i 0} {$i < 30} {incr i} { # At least one hardware watchpoint was hit. Check if both were. set string $expect_out(1,string) - if [regexp "Hardware watchpoint 2: args\\\[0\\\]\[^\r\]*\r\[^\r\]*\r\[^\r\]*Old value = $args_0\[^\r\]*\r\[^\r\]*New value = [expr $args_0+1]\r" $string] { + if [regexp "Hardware watchpoint 2: args\\\[0\\\]\[^\r\]*\r+\[^\r\]*\r+\[^\r\]*Old value = $args_0\[^\r\]*\r+\[^\r\]*New value = [expr $args_0+1]\r+" $string] { incr args_0 incr test_flag_0 } - if [regexp "Hardware watchpoint 3: args\\\[1\\\]\[^\r\]*\r\[^\r\]*\r\[^\r\]*Old value = $args_1\[^\r\]*\r\[^\r\]*New value = [expr $args_1+1]\r" $string] { + if [regexp "Hardware watchpoint 3: args\\\[1\\\]\[^\r\]*\r+\[^\r\]*\r+\[^\r\]*Old value = $args_1\[^\r\]*\r+\[^\r\]*New value = [expr $args_1+1]\r+" $string] { incr args_1 incr test_flag_1 }