From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16808 invoked by alias); 21 Nov 2007 23:33:36 -0000 Received: (qmail 16558 invoked by uid 22791); 21 Nov 2007 23:33:34 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Nov 2007 23:33:26 +0000 Received: by ug-out-1314.google.com with SMTP id o2so269176uge for ; Wed, 21 Nov 2007 15:33:24 -0800 (PST) Received: by 10.67.32.14 with SMTP id k14mr107298ugj.1195688003597; Wed, 21 Nov 2007 15:33:23 -0800 (PST) Received: from ?88.210.76.67? ( [88.210.76.67]) by mx.google.com with ESMTPS id 29sm1614061uga.2007.11.21.15.33.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Nov 2007 15:33:23 -0800 (PST) Message-ID: <4744C022.1030208@portugalmail.pt> Date: Wed, 21 Nov 2007 23:33:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Pierre Muller CC: gdb-patches@sourceware.org Subject: Re: [win32] Fix watchpoint support References: <47437D49.6080600@portugalmail.pt> <001401c82c52$4e72dcb0$eb589610$@u-strasbg.fr> In-Reply-To: <001401c82c52$4e72dcb0$eb589610$@u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-11/txt/msg00403.txt.bz2 Pierre Muller wrote: > Great, > > I tried it out and it seems indeed to work. > I got +35 expected passes and -14 unexpected failures, > there difference is probably due to several tests that are > not performed because of previous errors within the same > test. > I frequently see intermitent problems like: Running ../../../gdb-server_submit/src/gdb/testsuite/gdb.base/langs.exp ... PASS: gdb.base/langs.exp: break on nonexistent function in langs.exp -PASS: gdb.base/langs.exp: show language at csub in langs.exp -PASS: gdb.base/langs.exp: backtrace in langs.exp -PASS: gdb.base/langs.exp: up to foo in langs.exp -PASS: gdb.base/langs.exp: show language at foo in langs.exp -PASS: gdb.base/langs.exp: up to cppsub_ in langs.exp -PASS: gdb.base/langs.exp: show language at cppsub_ in langs.exp -PASS: gdb.base/langs.exp: up to fsub in langs.exp -PASS: gdb.base/langs.exp: show language at fsub in langs.exp -PASS: gdb.base/langs.exp: up to langs0__2do in langs.exp -PASS: gdb.base/langs.exp: show language at langs0__2do in langs.exp -PASS: gdb.base/langs.exp: up to main in langs.exp -PASS: gdb.base/langs.exp: show language at main in langs.exp -PASS: gdb.base/langs.exp: continue to exit in langs.exp +ERROR: Couldn't send show language to GDB. +UNRESOLVED: gdb.base/langs.exp: show language at csub in langs.exp +ERROR: Couldn't send bt to GDB. +UNRESOLVED: gdb.base/langs.exp: backtrace in langs.exp +ERROR: Couldn't send up to GDB. +UNRESOLVED: gdb.base/langs.exp: up to foo in langs.exp +ERROR: Couldn't send show language to GDB. +UNRESOLVED: gdb.base/langs.exp: show language at foo in langs.exp +ERROR: Couldn't send up to GDB. +UNRESOLVED: gdb.base/langs.exp: up to cppsub_ in langs.exp +ERROR: Couldn't send show language to GDB. +UNRESOLVED: gdb.base/langs.exp: show language at cppsub_ in langs.exp Or like: (...) -PASS: gdb.base/return2.exp: continue to double_func -PASS: gdb.base/return2.exp: return from double_func -PASS: gdb.base/return2.exp: double value returned successfully -PASS: gdb.base/return2.exp: validate result value not equal to program return value +gdb compile failed, exit status is 1 +UNTESTED: gdb.base/return2.exp: return2.exp The test that fails tends to change between runs. I find myself redoing those tests that failed to be sure it wasn't a regression. > Just out of curiosity, why did you choose 0xfff0ff0 > for dr[6]. The 80386 Programmer's Reference Manual says the debug handler should move zeros to DR6 to avoid confusion, but I've read somewhere that Windows expects it to be set to 0xffff0ff0 (undefined bits set to 1, could be 0xffff1ff0 too). Can't find the reference now. Bummer. In fact, if you search for it on google.com/codesearch, you'll see a lot of people choosing it too. I don't think it really makes a difference -- but that's no reason to keep a TODO there. I've tested with 0 and 0xffff0ff0, and saw no difference. -- Cheers, Pedro Alves