From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Patches Subject: [patch/todo] Move Move ``Hardware watchpint problems'' out of 5.1 Date: Fri, 16 Feb 2001 09:43:00 -0000 Message-id: <3A8D65A6.DFD525D7@cygnus.com> X-SW-Source: 2001-02/msg00296.html 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 * 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 : - - 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 : + + 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 To: Paul Hilfinger 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 > 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 > > * 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 > 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 > > * 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.