From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20478 invoked by alias); 16 Sep 2014 09:00:06 -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 20454 invoked by uid 89); 16 Sep 2014 09:00:05 -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; Tue, 16 Sep 2014 09:00:03 +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 1XTocB-0001Iu-Ed from Thomas_Schwinge@mentor.com ; Tue, 16 Sep 2014 01:59:59 -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; Tue, 16 Sep 2014 09:59:57 +0100 From: Thomas Schwinge To: Samuel Thibault CC: , Subject: Re: [PATCHv3,Hurd] Add hardware watch support In-Reply-To: <20140915230950.GB2942@type.youpi.perso.aquilenet.fr> References: <20140910224919.GP3244@type.youpi.perso.aquilenet.fr> <874mwcpvsy.fsf@schwinge.name> <87lhpko7um.fsf@schwinge.name> <20140915230950.GB2942@type.youpi.perso.aquilenet.fr> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 16 Sep 2014 09:00:00 -0000 Message-ID: <87iokondoc.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/msg00517.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 1419 Hi Samuel! On Tue, 16 Sep 2014 01:09:50 +0200, Samuel Thibault wrote: > Thomas Schwinge, le Tue 16 Sep 2014 00:08:01 +0200, a =C3=A9crit : > > Do you agree that thread_get_state(i386_DEBUG_STATE) should be > > returning the actual DR6, >=20 > Indeed. >=20 > > and where in GNU Mach would we need to copy the DR6 > > register into the PCB? >=20 > it would be user_trap(), probably, in the T_DEBUG case. Thanks for the pointer. Something like the following does accomplish its task w.r.t. GDB, but there are some TODO items. It might help to compare what the Linux kernel is doing; =C2=BBgit grep --cached -i dr6 -- arch/x86/= =C2=AB or similar. diff -ru gnumach-1.4.orig/i386/i386/trap.c gnumach-1.4/i386/i386/trap.c --- gnumach-1.4.orig/i386/i386/trap.c 2013-09-27 08:05:57.000000000 +0200 +++ gnumach-1.4/i386/i386/trap.c 2014-09-16 10:45:58.000000000 +0200 @@ -404,6 +404,17 @@ return 0; } #endif + + /* Make the content of the debug status register (DR6) + available to user space. */ + /* TODO: Do we have to sanitize its content? (Mask out + reserved bits?) */ + /* TODO: Where should its content be reset (zeroed)? From user + space? */ + /* TODO: Anything to take care about w.r.t interaction with + KDB? */ + thread->pcb->ims.ids.dr[6] =3D get_dr6(); + exc =3D EXC_BREAKPOINT; code =3D EXC_I386_SGL; break; Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUF/wDAAoJENuKOtuXzphJkZoH/3zrSEOBb+Y8Aijw9QRnChPw vBjGOxK3GhkMaMgU4gBzwD+UXEReHsdwsw9WoxSG8i9TWHPDrANekWc5hsunPF+e K/KSh/heXuctZ66Q+zBSM47fzKp5cjSvHqCC5hM+nGmqdYQ6PU84dCnSyUcsJTrK I9QLJtAdHUDYcUlxJuQOhy5GSq7yd5NlLn4dXrK2gJevkC/XzilI4vZlZo18VMcF g0F/Yfdrlew6YwU78caBIbw29JP3C6+3L254bbYXT+aQDomC1d/uMCmgFLsN2QBQ jrkSilypCdqE6ekHCt+kklucjphActPsq84/OJB+jojzIBkM383lLu+KHu5Lx44= =hSAi -----END PGP SIGNATURE----- --=-=-=--