From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5580 invoked by alias); 13 Mar 2009 07:59:59 -0000 Received: (qmail 5569 invoked by uid 22791); 13 Mar 2009 07:59:58 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_92 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; Fri, 13 Mar 2009 07:59:19 +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 n2D7xCK4026556 ; Fri, 13 Mar 2009 08:59:12 +0100 (CET) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n2D7xCCx014424 ; Fri, 13 Mar 2009 08:59:12 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n2D7xAxC040307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 13 Mar 2009 08:59:10 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Pedro Alves'" , References: <000901c9a372$89647070$9c2d5150$@u-strasbg.fr> <200903130102.50004.pedro@codesourcery.com> In-Reply-To: <200903130102.50004.pedro@codesourcery.com> Subject: RE: [RFC] Set I386_USE_GENERIC_WATCHPOINTS in configure Date: Fri, 13 Mar 2009 08:50:00 -0000 Message-ID: <000001c9a3b1$98a63ca0$c9f2b5e0$@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-03/txt/msg00197.txt.bz2 Hi Pedro, Thanks for the feedback. > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Friday, March 13, 2009 2:03 AM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [RFC] Set I386_USE_GENERIC_WATCHPOINTS in configure >=20 > On Friday 13 March 2009 00:27:47, Pierre Muller wrote: > > To get fully functional multi-arch, > > we should try to remove all nm files. >=20 > We need to make everything that is target dependent selectable > at runtime. Things that affect native debugging only can stay here > without any prejudice. E.g., not having watchpoints in the target > vector was something that was problematic for multi-target support, > hence the slow moving towards making I386_WATCHPOINTS_IN_TARGET_VECTOR > the default. A define that only affects the native target > is not problematic, since there's only ever one native > target configured in. Only one native target, but possibly several native object files, like linux64 could use both amd64-nat.c and i386-nat.c so that using direct functions could lead to=20 i386_dr_low_set_addr be implemented twice=20 in this case. > > > > I tried to write a patch that completely removes > > the need of > > I386_USE_GENERIC_WATCHPOINTS in config/i386/nm-*.h > > headers. > > Instead > > I386_USE_GENERIC_WATCHPOINTS and TARGET_HAS_DR_LEN_8 > > are set in configure. >=20 > Why do we need I386_USE_GENERIC_WATCHPOINTS at all? >=20 > The right way to do this is to only add i386-nat.o to > NATDEPFILES in configurations that want to use it. For fbsd, > you can guard the call to i386_use_watchpoints with > HAVE_PT_GETDBREGS, and completely get rid of > I386_USE_GENERIC_WATCHPOINTS. I still don't know how we should handle i386-nat.c in NATDEPFILES for FreeBSD then. =20 > I suggest we first eliminate I386_WATCHPOINTS_IN_TARGET_VECTOR > as a separate step, independently of the I386_USE_GENERIC_WATCHPOINTS > changes. OK, I can send a separate RFA for this. > > > > This allows to almost completely empty > > the config/i386/nm*.h files. > > > > I used four function variables to replace > > the I386_DR_LOW_* macros, and set those variables > > close to where i386_use_watchpoints function > > is called. > > I am not sure that this is the best solution, > > but I was afraid of the idea of implementing the > > same function in different sources, with a possible > > conflict if two of these native files get compiled into > > the same executable. >=20 > Not likely to happen anytime soon, if ever (cough). GDB can > only be configured for one native target. >=20 > > > > I am not really confident in the configure.ac part, > > as this is the first time I try to modify this > > file and I have no knowledge of autoconf :( > > > > All remarks are welcome. > > >=20 > I guess a new structure holding function pointers > would be cleaner. Say, >=20 > struct i386_watchpoint_ops > { > void (*dr_low_set_control) (unsigned); > void (*dr_low_set_addr) (int, CORE_ADDR); > void (*dr_low_reset_addr) (int); > unsigned (*dr_low_get_status) (void); > int dr_size; > }; >=20 > This removes the need for any configure.ac change, I believe. >=20 There is still the FreeBSD problem to solve... =20 > One thing that could be investigated is if exposing the > i386 debug registers through the register cache (exposed > as process wide registers, not per-thread registers) could > be a good interface for remote watchpoint support, thus making > remote targets benefit from the reference counting done on the > GDB side instead of implementing Z watchpoint packets. Not > sure yet how feasible or efficient that is. Could we do this later? With my patch, we would also simply=20 use the same file for windows gdbserver. My earlier RFC does almost the same change in gdbserver directory. http://sourceware.org/ml/gdb-patches/2009-02/msg00206.html The only change was for the debug printing, but this can also be easily taken care of by so function variable. But what are the rules here: can gdbserver use a source from gdb directory? If not, what are the options? Move the file to common directory? Pierre Muller Pascal language support maintainer for GDB