Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Wu Zhou <woodzltc@cn.ibm.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	gdb-patches@sources.redhat.com, 	mark@xs4all.nl, bje@au1.ibm.com,
	anton@au1.ibm.com
Subject: Re: [RFC] GDB patches for hw watchpoints - revised
Date: Sun, 22 Jan 2006 20:56:00 -0000	[thread overview]
Message-ID: <20060122205641.GF27224@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0512221241100.16314@localhost.localdomain>

Most of this looks good.  A couple bits don't though.

On Thu, Dec 22, 2005 at 12:47:18PM +0800, Wu Zhou wrote:
> 2005-12-22  Ben Elliston  <bje@au1.ibm.com>
> 	    Wu Zhou  <woodzltc@cn.ibm.com>
> 
> 	* rs6000-tdep.c (rs6000_gdbarch_init): If the macn is p630, set
> 	gdbarch to have nonsteppable watchpoint.

First, please don't abbreviate in changelogs.  Second, this code
doesn't make sense.  It sounds like you've only tested on p630,
whatever that is, which is fine - but watchpoints have nothing to do
with bfd_mach_ppc_p630.  Either the architecture has nonsteppable
watchpoints, or it doesn't.

> +   if (bfd_mach_ppc_630)
> +     set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1);

BTW:

../bfd/bfd-in2.h:#define bfd_mach_ppc_630       630

So I don't think this is testing what you wanted to, anyway :-)

> 	* ppc-linux-nat.c: Define three macro: PTRACE_GET_DEBUGREG,
> 	PTRACE_SET_DEBUGREG and PTRACE_GETSIGINFO. Define one static
> 	variable last_stopped_data_address.

Please use:

(PTRACE_GET_DEBUGREG, PTRACE_SET_DEBUGREG, PTRACE_GETSIGINFO): Define.
(last_stopped_data_address): New.

Can all the new functions in ppc-linux-nat.c be static?

> +   /* DABR (data address breakpoint register) is optional for PPC variations.
> +      Some variation have one DABR, others have none.  So CNT can't be larger
> +      than 1.  */

I believe you want "variants" in both places.

> +   /* We need to know whether ptrace syscall support PTRACE_SET_DEBUGREG and 
> +      whether the ppc arch have DABR.  If either answer is no, the ptrace call
> +      will return -1.  Return 0 for that.  */

  /* We need to know whether ptrace supports PTRACE_SET_DEBUGREG and whether the
     target has DABR.  If either answer is no, the ptrace call will return -1.
     Fail in that case.  */

> + static int
> + ppc_linux_region_size_ok_for_hw_watchpoint (int cnt)
> + {
> +   return 1;
> + }

The argument is LEN, not CNT.  It would be nice to do a useful check
here; I think that to do that, you'd need to move
TARGET_REGION_OK_FOR_HW_WATCHPOINT into the target vector.  You could
probably replace TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT and have the
current implementations ignore the address.

That would let you remove some failure cases from
target_insert_watchpoint.

Also, please remove the commented out version of
ppc_linux_stopped_data_address.


-- 
Daniel Jacobowitz
CodeSourcery


  parent reply	other threads:[~2006-01-22 20:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22 15:26 Wu Zhou
2005-12-22 15:38 ` Wu Zhou
2005-12-22 15:57   ` Eli Zaretskii
2005-12-22 15:57     ` Wu Zhou
2005-12-23 20:52       ` Eli Zaretskii
2006-01-22 20:56       ` Daniel Jacobowitz [this message]
2006-01-24  3:40         ` Wu Zhou
2006-01-24  3:43           ` Daniel Jacobowitz
2006-01-24  4:33             ` Wu Zhou
2006-01-24 11:00               ` Wu Zhou
2006-01-24 21:20                 ` Daniel Jacobowitz
2006-01-25  3:19                   ` Wu Zhou
2006-01-25  8:34                   ` Replace to_region_size_ok_for_hw_watchpoint references with to_region_ok_for_hw_watchpoint ones Wu Zhou
2006-02-02  1:43                     ` [RFC] GDB patches for hw watchpoints - revised Daniel Jacobowitz
2006-02-08  5:35                       ` Wu Zhou
2006-02-09  5:44                         ` Wu Zhou
2006-02-09  7:44                           ` Eli Zaretskii
2006-02-13  9:53                             ` Wu Zhou
  -- strict thread matches above, loose matches on Subject: below --
2005-12-06 19:54 Wu Zhou
2005-12-06 22:46 ` Ulrich Weigand
2005-12-09 12:00   ` Wu Zhou
2005-12-09 14:34     ` Ulrich Weigand
2005-12-06 23:05 ` Eli Zaretskii
2005-12-06 23:31   ` Daniel Jacobowitz
2005-12-09 12:04     ` Wu Zhou
2005-12-09 14:22       ` Daniel Jacobowitz
2005-12-09 18:58         ` Eli Zaretskii
2005-12-10 22:23         ` Wu Zhou
2005-12-11 11:12           ` Daniel Jacobowitz
2005-12-11 14:39             ` Wu Zhou
2005-12-13 22:47             ` Wu Zhou
2005-12-14 18:12               ` Eli Zaretskii
2005-12-14 18:13               ` Daniel Jacobowitz
2005-12-15 20:06                 ` Wu Zhou
2005-12-16  0:10                   ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060122205641.GF27224@nevyn.them.org \
    --to=drow@false.org \
    --cc=anton@au1.ibm.com \
    --cc=bje@au1.ibm.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mark@xs4all.nl \
    --cc=woodzltc@cn.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox