From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17919 invoked by alias); 2 Jun 2009 22:47:57 -0000 Received: (qmail 17908 invoked by uid 22791); 2 Jun 2009 22:47:55 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_38 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Jun 2009 22:47:48 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n52Mlb4H015181 ; Wed, 3 Jun 2009 00:47:37 +0200 (CEST) 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 n52MlbWu060135 ; Wed, 3 Jun 2009 00:47:37 +0200 (CEST) (envelope-from muller@ics.u-strasbg.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 n52Mla9C054153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 3 Jun 2009 00:47:36 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Doug Evans'" , "'Pedro Alves'" Cc: References: <20090430071853.99F5584890@localhost> <001201c9d860$e66c5850$b34508f0$@u-strasbg.fr> In-Reply-To: Subject: RE: [RFA] i386/amd64 h/w watchpoints in gdbserver Date: Tue, 02 Jun 2009 22:47:00 -0000 Message-ID: <000301c9e3d4$218eac20$64ac0460$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-06/txt/msg00026.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Doug Evans > Envoy=E9=A0: Tuesday, June 02, 2009 5:36 PM > =C0=A0: Pierre Muller; Pedro Alves > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFA] i386/amd64 h/w watchpoints in gdbserver >=20 > On Tue, May 19, 2009 at 2:05 AM, Pierre Muller strasbg.fr> wrote: > > =A0Doug, I think that your should send a new RFA for an up-to-date > patch > > with the bi-arch stuff. > > Do we have an automated testsuite result comparison script that can > be > > used for gdbserver testing? >=20 > I just use --target_board=3Dnative-gdbserver.exp and compare > before/after. > ref: http://sourceware.org/gdb/wiki/Native_gdbserver_testing >=20 > No regressions on amd64 gdbserver, 32-bit and 64-bit. Did you try to remove the line saying that=20 gdbserver does not support hardware watchpoints, does it change anything? =20 > > =A0I can test compilation on cygwin, > > but testing can only be done manually... >=20 > Thanks, can you give this a try? I was able to compile without problems and test gdb.base/watchpoint.exp and got 60 PASS (same as gdb itself). This is the board/hext-gdbserver.exp file I am using Both noargs and nofileio board infos are commented out, as gdb.base/args.exp and gdb.base/fileio.exp give the same results for gdbserver as for normal gdb (after the commenting out in this configuration file). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< # gdbserver running native. load_generic_config "gdbserver" process_multilib_options "" # The default compiler for this target. set_board_info compiler "[find_gcc]" # This gdbserver can only run a process once per session. # set_board_info gdb,do_reload_on_run 1 # There's no support for argument-passing (yet). # set_board_info noargs 1 # Can't do input (or output) in the current gdbserver. set_board_info gdb,noinferiorio 1 # gdbserver does not intercept target file operations and perform them # on the host. # set_board_info gdb,nofileio 1 # Can't do hardware watchpoints, in general. # set_board_info gdb,no_hardware_watchpoints 1 set_board_info sockethost "localhost:" #set_board_info use_gdb_stub 1 #set_board_info gdb_stub libgdbstub # We will be using the standard GDB remote protocol. set_board_info gdb_protocol "extended-remote" # Test the copy of gdbserver in the build directory. set_board_info gdb_server_prog "../gdbserver/gdbserver" proc ${board}_spawn { board cmd } { global board_info set baseboard [lindex [split $board "/"] 0] set board_info($baseboard,isremote) 0 set result [remote_spawn $board $cmd] set board_info($baseboard,isremote) 1 return $result } proc ${board}_download { board host dest } { return $host } proc ${board}_file { dest op args } { if { $op =3D=3D "delete" } { return 0 } return [eval [list standard_file $dest $op] $args] } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > =A0Hopefully, Pedro will then be able to review it rapidly. >=20 > There's one aspect of this patch that one might want changing. > [I'd like to see the change, fwiw.] >=20 > It's ok for higher level routines to refer to global state (within > reason), but it's less ok for lower level routines to refer to global > state (modulo constant tables and such that won't change for the > duration). The higher level routines should pass down context so the > lower level routines don't refer to any global state (again, within > reason). >=20 > Applying that principle here means routines in linux-x86-low.c, for > example, should not refer to any global state. > Shall I add parameters to insert_watchpoint, etc. so that, for example, > x86_insert_watchpoint doesn't have to call current_process? >=20 > Pedro: Note that this patch does defer updating the debug regs until > just before PTRACE_CONT. > [win32 version already did a similar thing] While I understand your considerations, I would prefer=20 that this patch gets approved as is. We can always try to improve it later. Pierre=20