[patch/todo] Move Move ``Hardware watchpint problems'' out of 5.1

Andrew Cagney
2001-02-16T09:43:00Z

FYI,

I've committed the attatched. This was snuck into the 5.1 release
criteria (and I should emphasise that the sneakering was not done by Eli
:-).

Doing this now is some what ironic as Eli has just turned his head
towards the problem and may well get it into 5.1!

I ment to do this months ago :-(

Andrew
2001-02-16 Andrew Cagney <ac131313@redhat.com>

* TODO (5.1): Move ``Hardware watchpint problems'' out of 5.1.

Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.58
diff -p -r1.58 TODO
*** TODO 2001/02/08 06:03:52 1.58
--- TODO 2001/02/16 17:38:17
*************** cycle. People hope to have these proble
*** 12,37 ****

--

- Hardware watchpint problems on x86 OSes, including Linux:
-
- 1. Delete/disable hardware watchpoints should free hardware debug
- registers.
- 2. Watch for different values on a viariable with one hardware debug
- register.
-
- According to Eli Zaretskii <eliz@delorie.com>:
-
- These are not GDB/ia32 issues per se: the above features are all
- implemented in the DJGPP port of GDB and work in v5.0. Every
- x86-based target should be able to lift the relevant parts of
- go32-nat.c and use them almost verbatim. You get debug register
- sharing through reference counts, and the ability to watch large
- regions (up to 16 bytes) using multiple registers. (The required
- infrastructure in high-level GDB application code, mostly in
- breakpoint.c, is also working since v5.0.)
-
- --
-
RFD: infrun.c: No bpstat_stop_status call after proceed over break?
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html

--- 12,17 ----
*************** coverage analysis).
*** 539,544 ****
--- 519,544 ----

These are harder than cleanups but easier than work involving
fundamental architectural change.
+
+ --
+
+ Hardware watchpint problems on x86 OSes, including Linux:
+
+ 1. Delete/disable hardware watchpoints should free hardware debug
+ registers.
+ 2. Watch for different values on a viariable with one hardware debug
+ register.
+
+ According to Eli Zaretskii <eliz@delorie.com>:
+
+ These are not GDB/ia32 issues per se: the above features are all
+ implemented in the DJGPP port of GDB and work in v5.0. Every
+ x86-based target should be able to lift the relevant parts of
+ go32-nat.c and use them almost verbatim. You get debug register
+ sharing through reference counts, and the ability to watch large
+ regions (up to 16 bytes) using multiple registers. (The required
+ infrastructure in high-level GDB application code, mostly in
+ breakpoint.c, is also working since v5.0.)

--

From law@redhat.com Fri Feb 16 09:46:00 2001
From: Jeffrey A Law <law@redhat.com>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: gdb-patches Digest 11 Feb 2001 23:49:53 -0000 Issue 545
Date: Fri, 16 Feb 2001 09:46:00 -0000
Message-id: <6986.982345742@slagheap.cygnus.com>
References: <981935393.6900.ezmlm@sources.redhat.com>
X-SW-Source: 2001-02/msg00297.html
Content-length: 2499

In message <981935393.6900.ezmlm@sources.redhat.com>you write:
> From: Paul Hilfinger <hilfingr@gnat.com>
> To: gdb-patches@sources.redhat.com
> Subject: RFC: patch to allow building on HPUX 11
> Message-Id: < 20010210235513.E298C34D80@nile.gnat.com >
> Date: Sat, 10 Feb 2001 18:55:13 -0500 (EST)
>
>
> I had to make the following patch to get the current sources to compile
> on HPUX 11.0.
>
> A related question: I also found that I needed to add -D__STDC_EXT__
> to CFLAGS in order to get uint64_t defined when used HP header files.
> Is this something that ought to be added to the configuration files, or is
> some other change appropriate instead?
This sounds like you're trying to build with gcc-2.95.x, which does not
support hpux11.

> 2001-02-11 Paul Hilfinger <hilfingr@lisbon.int.act-europe.fr>
>
> * hpux-thread.c (hpux_thread_xfer_memory): Add mem_attrib
> argument to parameter list and to call in order to conform to
> to_xfer_memory field of struct target_ops.
?!? I can't see how this can be right.

From target.h in the current CVS tree the to_xfer_memory signature looks
like this:

int (*to_xfer_memory) PARAMS ((CORE_ADDR memaddr, char *myaddr,
int len, int write,
struct target_ops * target));

Note, there is no mem_attrib argument.

> From: Paul Hilfinger <hilfingr@gnat.com>
> To: gdb-patches@sources.redhat.com
> Subject: RFC: Killing some warnings
> Message-Id: < 20010211075957.3E9F434D80@nile.gnat.com >
> Date: Sun, 11 Feb 2001 02:59:57 -0500 (EST)
>
>
> While I was mucking around with hpux-thread.c, I happened to notice that
> it contains an instance of make_cleanup that does not conform to the
> guidelines given in Cagney's comment in defs.h. Doesn't happen to cause
> any problems here, except for warnings, but I don't trust warnings. With
> this change, there will be no warnings unless the size of void* or int
> changes, at which point there SHOULD be one.
>
> Paul Hilfinger
> Ada Core Technologies
>
>
> 2001-02-11 Paul Hilfinger <hilfingr@nile.gnat.com>
>
> * hpux-thread.c (save_inferior_pid): Change call to make_cleanup
> to make arguments conform.
> (restore_inferior_pid): Change signature to that expected by
> make_cleanup.
No comment on this one -- I'm not that familiar with the new guidelines
for make_cleanup. I'll let Andrew comment on this.