From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16330 invoked by alias); 15 Sep 2014 22:08:21 -0000 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 Received: (qmail 16316 invoked by uid 89); 15 Sep 2014 22:08:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Sep 2014 22:08:15 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XTeRP-0004IJ-Pa from Thomas_Schwinge@mentor.com ; Mon, 15 Sep 2014 15:08:12 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Mon, 15 Sep 2014 23:08:10 +0100 From: Thomas Schwinge To: Samuel Thibault , CC: Subject: Re: [PATCHv3,Hurd] Add hardware watch support In-Reply-To: <874mwcpvsy.fsf@schwinge.name> References: <20140910224919.GP3244@type.youpi.perso.aquilenet.fr> <874mwcpvsy.fsf@schwinge.name> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Mon, 15 Sep 2014 22:08:00 -0000 Message-ID: <87lhpko7um.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2014-09/txt/msg00511.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 1696 Hi Samuel! On Fri, 12 Sep 2014 19:56:13 +0200, I wrote: > Many thanks for persisting with this patch. The GDB testsuite shows a > pretty good improvement! I'll try to assess the remaining issues >From a quick scan through the =C2=BBFAIL:.*watch=C2=AB matches, the follow= ing one issue should be relevant for a lot of the regressions: given, for example, the gdb.base/pr11022 test case, on GNU/Linux we see: $ gcc [...]/gdb/testsuite/gdb.base/pr11022.c -g -o pr11022 $ ./gdb -q -ex 'watch x' -ex run pr11022=20 [...] Hardware watchpoint 1: x =20=20=20=20 Old value =3D 0 New value =3D 42 main () at ../../W._C._Handy/gdb/testsuite/gdb.base/pr11022.c:28 28 j =3D i; /* expect HW watchpoint stop */ ... whereas on GNU Hurd we see: [...] Program received signal SIGTRAP, Trace/breakpoint trap. main () at ../../../W._C._Handy/gdb/testsuite/gdb.base/pr11022.c:28 28 j =3D i; /* expect HW watchpoint stop */ You may want to prepend =C2=BB-ex 'maintenance set show-debug-regs on'=C2= =AB to see some debugging output (and notice that =C2=BBwatchpoint_hit=C2=AB is missin= g on GNU Hurd). I tracked this down to gdb/nat/x86-dregs.c:x86_dr_stopped_data_address and x86_dr_stopped_by_watchpoint not returning the information as desired, and tracked that in turn down to our kernel interface always returning zero for DR6, the debug status register. See the comment in x86_dr_stopped_data_address for how GDB is using this information. Do you agree that thread_get_state(i386_DEBUG_STATE) should be returning the actual DR6, and where in GNU Mach would we need to copy the DR6 register into the PCB? Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUF2NBAAoJENuKOtuXzphJ9eMH+wUoDgmoKyzvWkixaWzCF5pG P3PjQtWPfjWhNBQlx/UmahMQQV2q3R2p4qSVf4HRez2NEhlQO/L2f01McUOaSH9+ rwGfIILLoP0VprWlgxFQSyFcnJh6AvGWaWwwkPYgihB3dpORVjiKsu8kWvhfnDHh yToVEOVIuM/LTGYFMAXCJSjMNXXeb5uX8fG/LEjJ/2WC8sNTK2flsaiO9Bowvylo 8Uz8MqOujqPR0nK2wR5mlZcT5u6+3IrBXmoKxfEIqVJXtVFmQX0ryGoPvQygc3Kd GAgqvBcOJ1SQ9TNWbEA8Jr3aid1HG6bdgfvLgR8Hh/A1DpjZ+bo+UYuOs2OQ9Fc= =2SO0 -----END PGP SIGNATURE----- --=-=-=--