[patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

Hello,

Here there are several things to notice:

- core GDB no longer refers to TARGET_HAS_HARDWARE_WATCHPOINTS
At one stage target.h had definitions dependant on this macro, but no 
more.  This patch removes the no-longer-needed defintion from 
configurations, such as GNU/Linux.

- procfs.c and i386v-nat.c do refer to TARGET_HAS_HARDWARE_WATCHPOINTS
These files should be replying on an autoconf test.  This patch replaces 
those cases with DEPRECATED_{PROCFS,I386V}_USE_HARDWARE_WATCHPOINTS macros.

That leaves no definition so this patch also removes the corresponding 
documentation.

Comments?
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 11215 bytes --]

Index: doc/ChangeLog

	* gdbint.texinfo (Algorithms): Delete reference to
	TARGET_HAS_HARDWARE_WATCHPOINTS.
	(Target Architecture Definition): Ditto.

Index: ChangeLog

	* procfs.c: Replace TARGET_HAS_HARDWARE_WATCHPOINTS with
	DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS.
	* i386v-nat.c: Replace TARGET_HAS_HARDWARE_WATCHPOINTS with
	DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS.
	* config/sparc/nm-sol2.h (TARGET_HAS_HARDWARE_WATCHPOINTS):
	Replace with DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS.
	* config/mips/nm-irix5.h (TARGET_HAS_HARDWARE_WATCHPOINTS):
	Replace with PROCFS_USE_HARDWARE_WATCHPOINTS.
	* config/i386/nm-i386sol2.h (TARGET_HAS_HARDWARE_WATCHPOINTS):
	Replace with DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS.
	* config/i386/nm-i386sco5.h (TARGET_HAS_HARDWARE_WATCHPOINTS):
	Replace with DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS.
	* config/i386/nm-i386.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/s390/nm-linux.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/pa/nm-hppah.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/ia64/nm-linux.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/frv/tm-frv.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* mips-tdep.c (mips_dump_tdep): Do not print same.

Index: i386v-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/i386v-nat.c,v
retrieving revision 1.14
diff -p -u -r1.14 i386v-nat.c
--- i386v-nat.c	19 Jan 2003 04:06:45 -0000	1.14
+++ i386v-nat.c	5 Sep 2004 13:03:21 -0000
@@ -46,7 +46,7 @@
 #include <sys/ioctl.h>
 #include <fcntl.h>
 
-#ifdef TARGET_HAS_HARDWARE_WATCHPOINTS
+#ifdef DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS
 #include <sys/debugreg.h>
 #endif
 
@@ -108,7 +108,7 @@ kernel_u_size (void)
   return (sizeof (struct user));
 }
 \f
-#ifdef TARGET_HAS_HARDWARE_WATCHPOINTS
+#ifdef DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS
 
 #if !defined (offsetof)
 #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
@@ -274,4 +274,4 @@ i386_stopped_by_watchpoint (int pid)
   return 0;
 }
 
-#endif /* TARGET_HAS_HARDWARE_WATCHPOINTS */
+#endif /* DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS */
Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.320
diff -p -u -r1.320 mips-tdep.c
--- mips-tdep.c	4 Sep 2004 00:16:56 -0000	1.320
+++ mips-tdep.c	5 Sep 2004 13:03:25 -0000
@@ -6606,9 +6606,6 @@ mips_dump_tdep (struct gdbarch *current_
 		      "mips_dump_tdep: TARGET_CAN_USE_HARDWARE_WATCHPOINT # %s\n",
 		      XSTRING (TARGET_CAN_USE_HARDWARE_WATCHPOINT
 			       (TYPE, CNT, OTHERTYPE)));
-  fprintf_unfiltered (file,
-		      "mips_dump_tdep: TARGET_HAS_HARDWARE_WATCHPOINTS # %s\n",
-		      XSTRING (TARGET_HAS_HARDWARE_WATCHPOINTS));
 #ifdef TRACE_CLEAR
   fprintf_unfiltered (file,
 		      "mips_dump_tdep: TRACE_CLEAR # %s\n",
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.58
diff -p -u -r1.58 procfs.c
--- procfs.c	27 Aug 2004 13:37:42 -0000	1.58
+++ procfs.c	5 Sep 2004 13:03:27 -0000
@@ -2875,7 +2875,7 @@ procfs_address_to_host_pointer (CORE_ADD
 int
 proc_set_watchpoint (procinfo *pi, CORE_ADDR addr, int len, int wflags)
 {
-#if !defined (TARGET_HAS_HARDWARE_WATCHPOINTS)
+#if !defined (DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS)
   return 0;
 #else
 /* Horrible hack!  Detect Solaris 2.5, because this doesn't work on 2.5 */
@@ -5279,7 +5279,7 @@ procfs_set_watchpoint (ptid_t ptid, CORE
 static int
 procfs_can_use_hw_breakpoint (int type, int cnt, int othertype)
 {
-#ifndef TARGET_HAS_HARDWARE_WATCHPOINTS
+#ifndef DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS
   return 0;
 #else
   /* Due to the way that proc_set_watchpoint() is implemented, host
Index: config/frv/tm-frv.h
===================================================================
RCS file: /cvs/src/src/gdb/config/frv/tm-frv.h,v
retrieving revision 1.5
diff -p -u -r1.5 tm-frv.h
--- config/frv/tm-frv.h	1 Aug 2004 14:37:01 -0000	1.5
+++ config/frv/tm-frv.h	5 Sep 2004 13:03:27 -0000
@@ -20,8 +20,6 @@
 
 /* This target uses an architecture vector for most architecture methods.  */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) \
 	frv_check_watch_resources (type, cnt, ot)
 extern int frv_check_watch_resources (int type, int cnt, int ot);
Index: config/i386/nm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-i386.h,v
retrieving revision 1.5
diff -p -u -r1.5 nm-i386.h
--- config/i386/nm-i386.h	17 Jan 2004 21:56:12 -0000	1.5
+++ config/i386/nm-i386.h	5 Sep 2004 13:03:27 -0000
@@ -26,10 +26,6 @@
 /* Targets should define this to use the generic x86 watchpoint support.  */
 #ifdef I386_USE_GENERIC_WATCHPOINTS
 
-#ifndef TARGET_HAS_HARDWARE_WATCHPOINTS
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-#endif
-
 /* Clear the reference counts and forget everything we knew about DRi.  */
 extern void i386_cleanup_dregs (void);
 
Index: config/i386/nm-i386sco5.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-i386sco5.h,v
retrieving revision 1.6
diff -p -u -r1.6 nm-i386sco5.h
--- config/i386/nm-i386sco5.h	3 Sep 2004 17:13:47 -0000	1.6
+++ config/i386/nm-i386sco5.h	5 Sep 2004 13:03:27 -0000
@@ -52,8 +52,10 @@ extern int kernel_u_size (void);
 
 /* Hardware-assisted breakpoints and watchpoints.  */
 
+/* NOTE: cagney/2004-09-04: Replace macro with autoconf test.  */
+#define DEPRECATED_I386V_USE_HARDWARE_WATCHPOINTS
+
 /* We can also do hardware watchpoints.  */
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 
 /* After a watchpoint trap, the PC points to the instruction which
Index: config/i386/nm-i386sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-i386sol2.h,v
retrieving revision 1.9
diff -p -u -r1.9 nm-i386sol2.h
--- config/i386/nm-i386sol2.h	10 Aug 2003 13:49:33 -0000	1.9
+++ config/i386/nm-i386sol2.h	5 Sep 2004 13:03:27 -0000
@@ -22,7 +22,8 @@
 
 #ifdef NEW_PROC_API	/* Solaris 6 and above can do HW watchpoints */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
+/* NOTE: cagney/2004-09-04: Replace with autoconf test.  */
+#define DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS
 
 /* The man page for proc4 on solaris 6 and 7 says that the system
    can support "thousands" of hardware watchpoints, but gives no
Index: config/ia64/nm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/ia64/nm-linux.h,v
retrieving revision 1.14
diff -p -u -r1.14 nm-linux.h
--- config/ia64/nm-linux.h	22 Aug 2004 16:32:35 -0000	1.14
+++ config/ia64/nm-linux.h	5 Sep 2004 13:03:28 -0000
@@ -45,8 +45,6 @@ extern int ia64_cannot_store_register (i
 
 /* Hardware watchpoints */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 
 /* The IA-64 architecture can step over a watch point (without triggering
Index: config/mips/nm-irix5.h
===================================================================
RCS file: /cvs/src/src/gdb/config/mips/nm-irix5.h,v
retrieving revision 1.9
diff -p -u -r1.9 nm-irix5.h
--- config/mips/nm-irix5.h	29 Jul 2004 21:36:58 -0000	1.9
+++ config/mips/nm-irix5.h	5 Sep 2004 13:03:28 -0000
@@ -22,7 +22,8 @@
 #include "config/nm-sysv4.h"
 #undef IN_SOLIB_DYNSYM_RESOLVE_CODE
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
+/* NOTE: cagney/2004-09-04: Replace macro with autoconf test.  */
+#define DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS
 
 /* TARGET_CAN_USE_HARDWARE_WATCHPOINT is now defined to go through
    the target vector.  For Irix5, procfs_can_use_hw_watchpoint()
Index: config/pa/nm-hppah.h
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/nm-hppah.h,v
retrieving revision 1.21
diff -p -u -r1.21 nm-hppah.h
--- config/pa/nm-hppah.h	11 Aug 2004 21:51:28 -0000	1.21
+++ config/pa/nm-hppah.h	5 Sep 2004 13:03:28 -0000
@@ -98,8 +98,6 @@ extern int hppa_require_detach (int, int
    10.20 will at least link.  However, the "can I use a fast watchpoint?"
    query will always return "No" for 10.20. */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 /* The PA can watch any number of locations (generic routines already check
    that all intermediates are in watchable memory locations). */
 extern int hppa_can_use_hw_watchpoint (int type, int cnt, int ot);
Index: config/s390/nm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/s390/nm-linux.h,v
retrieving revision 1.10
diff -p -u -r1.10 nm-linux.h
--- config/s390/nm-linux.h	18 Feb 2004 20:09:48 -0000	1.10
+++ config/s390/nm-linux.h	5 Sep 2004 13:03:28 -0000
@@ -45,7 +45,6 @@ extern int s390_stopped_by_watchpoint (v
 extern int s390_insert_watchpoint (CORE_ADDR addr, int len);
 extern int s390_remove_watchpoint (CORE_ADDR addr, int len);
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 #define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr, len) 1
 #define HAVE_CONTINUABLE_WATCHPOINT 1
Index: config/sparc/nm-sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/nm-sol2.h,v
retrieving revision 1.2
diff -p -u -r1.2 nm-sol2.h
--- config/sparc/nm-sol2.h	3 Jan 2004 10:08:45 -0000	1.2
+++ config/sparc/nm-sol2.h	5 Sep 2004 13:03:28 -0000
@@ -33,7 +33,8 @@
 /* Solaris 2.6 and above can do HW watchpoints.  */
 #ifdef NEW_PROC_API
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
+/* NOTE: cagney/2004-09-04: Replace macro with autoconf test.  */
+#define DEPRECATED_PROCFS_USE_HARDWARE_WATCHPOINTS
 
 /* The man page for proc(4) on Solaris 2.6 and up says that the system
    can support "thousands" of hardware watchpoints, but gives no
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.222
diff -p -u -r1.222 gdbint.texinfo
--- doc/gdbint.texinfo	3 Sep 2004 17:13:48 -0000	1.222
+++ doc/gdbint.texinfo	5 Sep 2004 13:03:34 -0000
@@ -400,10 +400,6 @@ section is mostly irrelevant for softwar
 watchpoints:
 
 @table @code
-@findex TARGET_HAS_HARDWARE_WATCHPOINTS
-@item TARGET_HAS_HARDWARE_WATCHPOINTS
-If defined, the target supports hardware watchpoints.
-
 @findex TARGET_CAN_USE_HARDWARE_WATCHPOINT
 @item TARGET_CAN_USE_HARDWARE_WATCHPOINT (@var{type}, @var{count}, @var{other})
 Return the number of hardware watchpoints of type @var{type} that are
@@ -3833,11 +3829,6 @@ pointer in use at the code address @var{
 are not used, a default definition simply returns
 @code{DEPRECATED_FP_REGNUM}, with an offset of zero.
 
-@item TARGET_HAS_HARDWARE_WATCHPOINTS
-If non-zero, the target has support for hardware-assisted
-watchpoints.  @xref{Algorithms, watchpoints}, for more details and
-other related macros.
-
 @item TARGET_PRINT_INSN (@var{addr}, @var{info})
 @findex TARGET_PRINT_INSN
 This is the function used by @value{GDBN} to print an assembly

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Sun, 05 Sep 2004 09:27:17 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> - procfs.c and i386v-nat.c do refer to TARGET_HAS_HARDWARE_WATCHPOINTS
> These files should be replying on an autoconf test.

Autoconf tests don't work well for a cross-compiled GDB, and probably
will not work for anything but a native version of GDB.  Is procfs.c
used by some non-native target?

In any case, I'd like to see the suggested Autoconf replacement for
this before we deprecate the feature.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>> Date: Sun, 05 Sep 2004 09:27:17 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>> - procfs.c and i386v-nat.c do refer to TARGET_HAS_HARDWARE_WATCHPOINTS
>>> These files should be replying on an autoconf test.
> 
> 
> Autoconf tests don't work well for a cross-compiled GDB, and probably
> will not work for anything but a native version of GDB.  Is procfs.c
> used by some non-native target?

procfs.c is native only, the deprecated macros being defined in an 
nm-*.h file.

I'll clarify the comments so that it is clear that:

- it is native only

- in all likelyhood all applicable current systems support this 
mechanism so no autoconf test is needed (someone needs to do a proper 
analysis)

- its a configuration change, possibly involving an autoconf test

> In any case, I'd like to see the suggested Autoconf replacement for
> this before we deprecate the feature.

This is neither deprecating a feature, nor deprecating a system.

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Mon, 06 Sep 2004 10:05:02 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> I'll clarify the comments so that it is clear that:
> 
> - it is native only
> 
> - in all likelyhood all applicable current systems support this 
> mechanism so no autoconf test is needed (someone needs to do a proper 
> analysis)
> 
> - its a configuration change, possibly involving an autoconf test

Sorry, I'm confused: what will a non-native port do to support both
targets that have hardware watchpoints and those which do not?  Or are
you saying that _all_ targets have hardware watchpoint support now
(which I think is not true)?

> > In any case, I'd like to see the suggested Autoconf replacement for
> > this before we deprecate the feature.
> 
> This is neither deprecating a feature, nor deprecating a system.

``The feature'' in question is TARGET_HAS_HARDWARE_WATCHPOINTS.  It is
being deprecated/removed, isn't it?

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>>> > In any case, I'd like to see the suggested Autoconf replacement for
>>>> > this before we deprecate the feature.
>>
>>> 
>>> This is neither deprecating a feature, nor deprecating a system.
> 
> 
> ``The feature'' in question is TARGET_HAS_HARDWARE_WATCHPOINTS.  It is
> being deprecated/removed, isn't it?

The macro TARGET_HAS_HARDWARE_WATCHPOINTS is just a mechanism that core 
GDB might use (it doesn't) when implementing a [user visible] feature 
such as ``hardware watchpoints''.  I'm not ``expressing disapproval of 
or wishing against'' the feature ``hardware watchpoints'', nor am I 
``expressing disapproval of or wishing against'' systems that provide 
the feature ``hardware watchpoints''.

However, I am formalizing our disapproval of the macro 
TARGET_HAS_HARDWARE_WATCHPOINTS.  To which I wrote:

> Here there are several things to notice:
> 
> - core GDB no longer refers to TARGET_HAS_HARDWARE_WATCHPOINTS
> At one stage target.h had definitions dependant on this macro, but no more.  This patch removes the no-longer-needed defintion from configurations, such as GNU/Linux.
> 
> - procfs.c and i386v-nat.c do refer to TARGET_HAS_HARDWARE_WATCHPOINTS
> These files should be replying on an autoconf test.  This patch replaces those cases with DEPRECATED_{PROCFS,I386V}_USE_HARDWARE_WATCHPOINTS macros.
> 
> That leaves no definition so this patch also removes the corresponding documentation.

Regarding the second of those points, procfs.c and i386v-nat.c:

>>> Date: Mon, 06 Sep 2004 10:05:02 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: gdb-patches@sources.redhat.com
>>> 
>>> I'll clarify the comments so that it is clear that:
>>> 
>>> - it is native only
>>> 
>>> - in all likelyhood all applicable current systems support this 
>>> mechanism so no autoconf test is needed (someone needs to do a proper 
>>> analysis)
>>> 
>>> - its a configuration change, possibly involving an autoconf test
> 
> 
> Sorry, I'm confused: what will a non-native port do to support both
> targets that have hardware watchpoints and those which do not?  Or are
> you saying that _all_ targets have hardware watchpoint support now
> (which I think is not true)?

(my comments were for the native case only).

For the non-native case, as I initially indicated and as an examination 
of the code reveals, this macro is never used!  Consequently I've in no 
way motified or altered GDB's ``hardware watchpoints'' feature on those 
targets.

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Tue, 07 Sep 2004 17:19:50 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> For the non-native case, as I initially indicated and as an examination 
> of the code reveals, this macro is never used!  Consequently I've in no 
> way motified or altered GDB's ``hardware watchpoints'' feature on those 
> targets.

Yes, you have: your patch, when checked in, will leave no way to build
a port for a target that has no hardware watchpoint support.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>> Date: Tue, 07 Sep 2004 17:19:50 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: gdb-patches@sources.redhat.com
>>> 
>>> For the non-native case, as I initially indicated and as an examination 
>>> of the code reveals, this macro is never used!  Consequently I've in no 
>>> way motified or altered GDB's ``hardware watchpoints'' feature on those 
>>> targets.
> 
> 
> Yes, you have: your patch, when checked in, will leave no way to build
> a port for a target that has no hardware watchpoint support.

Can you give an example - a target with no watchpoint support that no 
longer builds due to my patch?

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Wed, 08 Sep 2004 10:28:26 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> Can you give an example - a target with no watchpoint support that no 
> longer builds due to my patch?

I don't think it is my job to find such a target.  Rather, it is up to
you to prove that no target will ever need that.

Anyway, I don't think this kind of approach to our argument is
productive.  I suggest that we instead concentrate on finding an
alternative machinery to compute TARGET_HAS_HARDWARE_WATCHPOINTS at
configure time.

How about this: for a cross-compiled build or for remote targets, add
a switch to the configure script, say --without-hw-watchpoints, that
will set TARGET_HAS_HARDWARE_WATCHPOINTS so as to disable hardware
watchpoint support; for native and non-cross builds, add an autoconf
test that will do that automatically?

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Daniel Jacobowitz]

On Wed, Sep 08, 2004 at 06:17:38PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 08 Sep 2004 10:28:26 -0400
> > From: Andrew Cagney <cagney@gnu.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > Can you give an example - a target with no watchpoint support that no 
> > longer builds due to my patch?
> 
> I don't think it is my job to find such a target.  Rather, it is up to
> you to prove that no target will ever need that.
> 
> Anyway, I don't think this kind of approach to our argument is
> productive.  I suggest that we instead concentrate on finding an
> alternative machinery to compute TARGET_HAS_HARDWARE_WATCHPOINTS at
> configure time.
> 
> How about this: for a cross-compiled build or for remote targets, add
> a switch to the configure script, say --without-hw-watchpoints, that
> will set TARGET_HAS_HARDWARE_WATCHPOINTS so as to disable hardware
> watchpoint support; for native and non-cross builds, add an autoconf
> test that will do that automatically?

Why should the macro matter for remote targets?  We should ask the
target whether watchpoints are available.

For cross-compiled build, autoconf should work just fine.  Compile
tests are still available and you shouldn't be using run tests for this
sort of thing anyway.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Wed, 8 Sep 2004 11:23:15 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
> 
> Why should the macro matter for remote targets?  We should ask the
> target whether watchpoints are available.

So you are suggesting to replace a configure-time test and the macro
with a run-time test?

> For cross-compiled build, autoconf should work just fine.  Compile
> tests are still available and you shouldn't be using run tests for this
> sort of thing anyway.

I don't think this kind of test can be done by compiling a program,
but if you have a specific test in mind, please describe it.

In any case, if what you suggest works, I agree to replacing the macro
with these alternatives.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Daniel Jacobowitz]

On Thu, Sep 09, 2004 at 06:39:52AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 8 Sep 2004 11:23:15 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
> > 
> > Why should the macro matter for remote targets?  We should ask the
> > target whether watchpoints are available.
> 
> So you are suggesting to replace a configure-time test and the macro
> with a run-time test?

There are already some runtime tests for this.  I don't know how well
they all work, but I thought they did.  I never implemented watchpoints
for gdbserver, so I never tried them.

> 
> > For cross-compiled build, autoconf should work just fine.  Compile
> > tests are still available and you shouldn't be using run tests for this
> > sort of thing anyway.
> 
> I don't think this kind of test can be done by compiling a program,
> but if you have a specific test in mind, please describe it.
> 
> In any case, if what you suggest works, I agree to replacing the macro
> with these alternatives.

There are two cases:
  - If we enabled support, GDB could not be compiled.  This is amenable
    to compile tests.
  - If we enabled support, it would not work at runtime.  This is
    amenable only to runtime tests - either run during configure or run
    during execution.  I strongly believe the former are wrong in all
    but exceptional cases.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Wed, 8 Sep 2004 23:53:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
> 
> > > For cross-compiled build, autoconf should work just fine.  Compile
> > > tests are still available and you shouldn't be using run tests for this
> > > sort of thing anyway.
> > 
> > I don't think this kind of test can be done by compiling a program,
> > but if you have a specific test in mind, please describe it.
> > 
> > In any case, if what you suggest works, I agree to replacing the macro
> > with these alternatives.
> 
> There are two cases:
>   - If we enabled support, GDB could not be compiled.  This is amenable
>     to compile tests.
>   - If we enabled support, it would not work at runtime.  This is
>     amenable only to runtime tests - either run during configure or run
>     during execution.  I strongly believe the former are wrong in all
>     but exceptional cases.

I understand the theory, I just don't know how to test for watchpoint
support in a program by just compiling it.  If you can suggest a
program whose compilation will reveal that, please do.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Daniel Jacobowitz]

On Thu, Sep 09, 2004 at 07:02:07AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 8 Sep 2004 23:53:37 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
> > 
> > > > For cross-compiled build, autoconf should work just fine.  Compile
> > > > tests are still available and you shouldn't be using run tests for this
> > > > sort of thing anyway.
> > > 
> > > I don't think this kind of test can be done by compiling a program,
> > > but if you have a specific test in mind, please describe it.
> > > 
> > > In any case, if what you suggest works, I agree to replacing the macro
> > > with these alternatives.
> > 
> > There are two cases:
> >   - If we enabled support, GDB could not be compiled.  This is amenable
> >     to compile tests.
> >   - If we enabled support, it would not work at runtime.  This is
> >     amenable only to runtime tests - either run during configure or run
> >     during execution.  I strongly believe the former are wrong in all
> >     but exceptional cases.
> 
> I understand the theory, I just don't know how to test for watchpoint
> support in a program by just compiling it.  If you can suggest a
> program whose compilation will reveal that, please do.

There's nothing generic controlled by TARGET_HAS_HARDWARE_WATCHPOINTS.
It controls an include of <sys/debugreg.h> in i386v-nat.c - that can be
autoconf'd, and then checked for the appropriate DR_* constants if
that's necessary.  It controls the use of prwatch_t in procfs.c,
likewise.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Thu, 9 Sep 2004 08:47:56 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
> 
> > I understand the theory, I just don't know how to test for watchpoint
> > support in a program by just compiling it.  If you can suggest a
> > program whose compilation will reveal that, please do.
> 
> There's nothing generic controlled by TARGET_HAS_HARDWARE_WATCHPOINTS.
> It controls an include of <sys/debugreg.h> in i386v-nat.c - that can be
> autoconf'd, and then checked for the appropriate DR_* constants if
> that's necessary.  It controls the use of prwatch_t in procfs.c,
> likewise.

I'm not sure the mere presence of DR_* automatically means that
hardware watchpoints are supported at run time.  I'd prefer to hear
that from Mark or someone else who could tell for sure.

In any case, if the above is true, then there should be no problem to
write an Autoconf test that would replace
TARGET_HAS_HARDWARE_WATCHPOINTS.  As soon as that is posted here, I
will withdraw all my objections to removing the old macro in favor of
the new mechanism.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>Date: Thu, 9 Sep 2004 08:47:56 -0400
>>> From: Daniel Jacobowitz <drow@false.org>
>>> Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
>>> 
>>
>>>> > I understand the theory, I just don't know how to test for watchpoint
>>>> > support in a program by just compiling it.  If you can suggest a
>>>> > program whose compilation will reveal that, please do.
>>
>>> 
>>> There's nothing generic controlled by TARGET_HAS_HARDWARE_WATCHPOINTS.
>>> It controls an include of <sys/debugreg.h> in i386v-nat.c - that can be
>>> autoconf'd, and then checked for the appropriate DR_* constants if
>>> that's necessary.  It controls the use of prwatch_t in procfs.c,
>>> likewise.
> 
> 
> I'm not sure the mere presence of DR_* automatically means that
> hardware watchpoints are supported at run time.  I'd prefer to hear
> that from Mark or someone else who could tell for sure.
> 
> In any case, if the above is true, then there should be no problem to
> write an Autoconf test that would replace
> TARGET_HAS_HARDWARE_WATCHPOINTS.  As soon as that is posted here, I
> will withdraw all my objections to removing the old macro in favor of
> the new mechanism.

This assumes that we've access to machines to test it on, and the code 
being modified is even being used / worth retaining.  Resolving both of 
those takes this from a no-problem task to something best handled 
separatly, and something that should not block this current patch.

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Sun, 12 Sep 2004 12:31:23 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
> 
> > I'm not sure the mere presence of DR_* automatically means that
> > hardware watchpoints are supported at run time.  I'd prefer to hear
> > that from Mark or someone else who could tell for sure.
> > 
> > In any case, if the above is true, then there should be no problem to
> > write an Autoconf test that would replace
> > TARGET_HAS_HARDWARE_WATCHPOINTS.  As soon as that is posted here, I
> > will withdraw all my objections to removing the old macro in favor of
> > the new mechanism.
> 
> This assumes that we've access to machines to test it on, and the code 
> being modified is even being used / worth retaining.  Resolving both of 
> those takes this from a no-problem task to something best handled 
> separatly, and something that should not block this current patch.

Sorry, the person who wants to submit a patch for inclusion should do
the necessary reasearch required to verify that the patch is doing
TRT.  Saying that this makes an easy job somewhat harder does not
change anything, I'm sure you've requested other contributors to do
the same in the past, and rightly so.

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

>>> Date: Sun, 12 Sep 2004 12:31:23 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
>>> 
>>
>>>> > I'm not sure the mere presence of DR_* automatically means that
>>>> > hardware watchpoints are supported at run time.  I'd prefer to hear
>>>> > that from Mark or someone else who could tell for sure.
>>>> > 
>>>> > In any case, if the above is true, then there should be no problem to
>>>> > write an Autoconf test that would replace
>>>> > TARGET_HAS_HARDWARE_WATCHPOINTS.  As soon as that is posted here, I
>>>> > will withdraw all my objections to removing the old macro in favor of
>>>> > the new mechanism.
>>
>>> 
>>> This assumes that we've access to machines to test it on, and the code 
>>> being modified is even being used / worth retaining.  Resolving both of 
>>> those takes this from a no-problem task to something best handled 
>>> separatly, and something that should not block this current patch.

I've committed this part of my change:

> - core GDB no longer refers to TARGET_HAS_HARDWARE_WATCHPOINTS
> At one stage target.h had definitions dependant on this macro, but no more.  This patch removes the no-longer-needed defintion from configurations, such as GNU/Linux.

w.r.t.,

> Sorry, the person who wants to submit a patch for inclusion should do
> the necessary reasearch required to verify that the patch is doing
> TRT.

That was done.  To have anyone do more is a waste of effort.

Anyway, this is all have been beaten to death in this thread, we are
just reiterating the same issues again and again.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 4487 bytes --]

2004-09-13  Andrew Cagney  <cagney@gnu.org>

	* config/i386/nm-i386.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/s390/nm-linux.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/pa/nm-hppah.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/ia64/nm-linux.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* config/frv/tm-frv.h (TARGET_HAS_HARDWARE_WATCHPOINTS): Delete.
	* mips-tdep.c (mips_dump_tdep): Do not print same.

Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.322
diff -p -u -r1.322 mips-tdep.c
--- mips-tdep.c	5 Sep 2004 20:15:40 -0000	1.322
+++ mips-tdep.c	13 Sep 2004 14:04:29 -0000
@@ -6604,9 +6604,6 @@ mips_dump_tdep (struct gdbarch *current_
 		      "mips_dump_tdep: TARGET_CAN_USE_HARDWARE_WATCHPOINT # %s\n",
 		      XSTRING (TARGET_CAN_USE_HARDWARE_WATCHPOINT
 			       (TYPE, CNT, OTHERTYPE)));
-  fprintf_unfiltered (file,
-		      "mips_dump_tdep: TARGET_HAS_HARDWARE_WATCHPOINTS # %s\n",
-		      XSTRING (TARGET_HAS_HARDWARE_WATCHPOINTS));
 #ifdef TRACE_CLEAR
   fprintf_unfiltered (file,
 		      "mips_dump_tdep: TRACE_CLEAR # %s\n",
Index: config/frv/tm-frv.h
===================================================================
RCS file: /cvs/src/src/gdb/config/frv/tm-frv.h,v
retrieving revision 1.5
diff -p -u -r1.5 tm-frv.h
--- config/frv/tm-frv.h	1 Aug 2004 14:37:01 -0000	1.5
+++ config/frv/tm-frv.h	13 Sep 2004 14:04:29 -0000
@@ -20,8 +20,6 @@
 
 /* This target uses an architecture vector for most architecture methods.  */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) \
 	frv_check_watch_resources (type, cnt, ot)
 extern int frv_check_watch_resources (int type, int cnt, int ot);
Index: config/i386/nm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-i386.h,v
retrieving revision 1.5
diff -p -u -r1.5 nm-i386.h
--- config/i386/nm-i386.h	17 Jan 2004 21:56:12 -0000	1.5
+++ config/i386/nm-i386.h	13 Sep 2004 14:04:29 -0000
@@ -26,10 +26,6 @@
 /* Targets should define this to use the generic x86 watchpoint support.  */
 #ifdef I386_USE_GENERIC_WATCHPOINTS
 
-#ifndef TARGET_HAS_HARDWARE_WATCHPOINTS
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-#endif
-
 /* Clear the reference counts and forget everything we knew about DRi.  */
 extern void i386_cleanup_dregs (void);
 
Index: config/ia64/nm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/ia64/nm-linux.h,v
retrieving revision 1.14
diff -p -u -r1.14 nm-linux.h
--- config/ia64/nm-linux.h	22 Aug 2004 16:32:35 -0000	1.14
+++ config/ia64/nm-linux.h	13 Sep 2004 14:04:29 -0000
@@ -45,8 +45,6 @@ extern int ia64_cannot_store_register (i
 
 /* Hardware watchpoints */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 
 /* The IA-64 architecture can step over a watch point (without triggering
Index: config/pa/nm-hppah.h
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/nm-hppah.h,v
retrieving revision 1.21
diff -p -u -r1.21 nm-hppah.h
--- config/pa/nm-hppah.h	11 Aug 2004 21:51:28 -0000	1.21
+++ config/pa/nm-hppah.h	13 Sep 2004 14:04:29 -0000
@@ -98,8 +98,6 @@ extern int hppa_require_detach (int, int
    10.20 will at least link.  However, the "can I use a fast watchpoint?"
    query will always return "No" for 10.20. */
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
-
 /* The PA can watch any number of locations (generic routines already check
    that all intermediates are in watchable memory locations). */
 extern int hppa_can_use_hw_watchpoint (int type, int cnt, int ot);
Index: config/s390/nm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/s390/nm-linux.h,v
retrieving revision 1.10
diff -p -u -r1.10 nm-linux.h
--- config/s390/nm-linux.h	18 Feb 2004 20:09:48 -0000	1.10
+++ config/s390/nm-linux.h	13 Sep 2004 14:04:29 -0000
@@ -45,7 +45,6 @@ extern int s390_stopped_by_watchpoint (v
 extern int s390_insert_watchpoint (CORE_ADDR addr, int len);
 extern int s390_remove_watchpoint (CORE_ADDR addr, int len);
 
-#define TARGET_HAS_HARDWARE_WATCHPOINTS
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 #define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr, len) 1
 #define HAVE_CONTINUABLE_WATCHPOINT 1

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Mon, 13 Sep 2004 10:27:59 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: drow@false.org, gdb-patches@sources.redhat.com
> 
> I've committed this part of my change:

Great!  So you've gone out and committed a patch over an objection of
a core maintainer who worked quite a bit on the releated code.  What
next?  I revert the patch and we start a patch-reverting war?

Don't you see how your unilateral conduct leads us directly to where
none of us wants to go?

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>Date: Mon, 13 Sep 2004 10:27:59 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: drow@false.org, gdb-patches@sources.redhat.com
>>> 
>>> I've committed this part of my change:
> 
> 
> Great!  So you've gone out and committed a patch over an objection of
> a core maintainer who worked quite a bit on the releated code.

No.  The changes that in anyway formalize the deprecation of all this:

cagney@nettle$ frep TARGET_HAS_HARDWARE_WATCHPOINTS
config/i386/nm-i386sco5.h:56:#define TARGET_HAS_HARDWARE_WATCHPOINTS
config/i386/nm-i386sol2.h:25:#define TARGET_HAS_HARDWARE_WATCHPOINTS
config/mips/nm-irix5.h:25:#define TARGET_HAS_HARDWARE_WATCHPOINTS
config/sparc/nm-sol2.h:36:#define TARGET_HAS_HARDWARE_WATCHPOINTS
doc/gdbint.texinfo:403:@findex TARGET_HAS_HARDWARE_WATCHPOINTS
doc/gdbint.texinfo:404:@item TARGET_HAS_HARDWARE_WATCHPOINTS
doc/gdbint.texinfo:3836:@item TARGET_HAS_HARDWARE_WATCHPOINTS
i386v-nat.c:45:#ifdef TARGET_HAS_HARDWARE_WATCHPOINTS
i386v-nat.c:107:#ifdef TARGET_HAS_HARDWARE_WATCHPOINTS
i386v-nat.c:273:#endif /* TARGET_HAS_HARDWARE_WATCHPOINTS */
procfs.c:2878:#if !defined (TARGET_HAS_HARDWARE_WATCHPOINTS)
procfs.c:5282:#ifndef TARGET_HAS_HARDWARE_WATCHPOINTS

and that you have so stridently objected to, are still all sitting on 
the table.

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Mon, 13 Sep 2004 16:46:05 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> > Great!  So you've gone out and committed a patch over an objection of
> > a core maintainer who worked quite a bit on the releated code.
> 
> No.  The changes that in anyway formalize the deprecation of all this:
> [...]
> and that you have so stridently objected to, are still all sitting on 
> the table.

That doesn't matter: you still did something unilaterally instead of
first asking if that is okay with me and others.

No matter how much you are annoyed by failing to get an agreement, it
doesn't mean you should do things unilaterally.  There's nothing
wrong, in principle, in the fact that I object to something ``so
stridently''; others, yourself included, are known to use the same
practices on many occasions.  AFIR, no one has as yet committed a
patch over your objections in such a situation.  I request that you do
the same here and in similar cases in the future.

TIA

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Andrew Cagney]

>>> Date: Mon, 13 Sep 2004 16:46:05 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: gdb-patches@sources.redhat.com
>>> 
>>
>>>> > Great!  So you've gone out and committed a patch over an objection of
>>>> > a core maintainer who worked quite a bit on the releated code.
>>
>>> 
>>> No.  The changes that in anyway formalize the deprecation of all this:
>>> [...]
>>> and that you have so stridently objected to, are still all sitting on 
>>> the table.
> 
> 
> That doesn't matter: you still did something unilaterally instead of
> first asking if that is okay with me and others.

Can you please provide a technical objection for the patch I committed. 
  None, that were not resolved, were identified during this discussion.

> No matter how much you are annoyed by failing to get an agreement, it
> doesn't mean you should do things unilaterally.  There's nothing
> wrong, in principle, in the fact that I object to something ``so
> stridently''; others, yourself included, are known to use the same
> practices on many occasions.  AFIR, no one has as yet committed a
> patch over your objections in such a situation.  I request that you do
> the same here and in similar cases in the future.

I've posted my fair share of "whatever"s.

Andrew

Re: [patch/rfc] Eliminate TARGET_HAS_HARDWARE_WATCHPOINTS

[Eli Zaretskii]

> Date: Wed, 15 Sep 2004 12:09:18 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> > That doesn't matter: you still did something unilaterally instead of
> > first asking if that is okay with me and others.
> 
> Can you please provide a technical objection for the patch I committed. 

My point was procedural, not technical.

This discussion identified a disagreement.  When there is a
disagreement, it is customary to ask for explicit approval to
compromise solutions before implementing them, even if you are sure
such an approval will be given.  If nothing else, this encourages
cooperation and the will to reach an agreement in the future.
Unilateral actions, OTOH, have the reverse effect.