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

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

[Andrew Cagney]

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.

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

[Eli Zaretskii]

> Date: Fri, 16 Feb 2001 12:38:46 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> 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!

My schedule is mostly driven by the free time I have, when I have it ;-)

(Actually, I expected 5.1 to be out by now.)