Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Wu Zhou <woodzltc@cn.ibm.com>
To: gdb-patches@sources.redhat.com
Cc: drow@false.org, eliz@gnu.org, mark.kettenis@xs4all.nl,
	kevinb@redhat.com,         uweigand@de.ibm.com, bje@au1.ibm.com,
	anton@au1.ibm.com
Subject: About the patch to add h/w watchpoint to ppc arch
Date: Fri, 06 Jan 2006 05:41:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0601061335390.18087@localhost.localdomain> (raw)

Hello maintainers,

We have discussed a lot about this patch.  And I had made some modification
to the original to make it more acceptable.  I am now revisiting the patch
to see whether it is ok to check it in.

The latest patch is at:
  http://sourceware.org/ml/gdb-patches/2005-12/msg00250.html

It addressed the issue of getting the stopped data address. Eli said that it
made sense.  Others didn't replied.  Could I take this as no objection? :-)
Said that, I am still very open to different opinions.  Suggestion for 
improvement are highly appreciated!

I am not sure whether there are any other problems hindering its acceptance.
The patch didn't add anything more to nm.h now(Thanks Mark, Ulrich ... for 
suggesting ways to achieve this); It tested ok on p630(will try to find other
ppc machines to test this); It uses run-time check to see whether kernel
support DABR manipulation or whether target machine have DABR registers.

One issue might be that some 32-bits ppc cpu might have more than one DABRs
(I am not sure which ones have >1 DABRs, Daniel and Anton suggested that). 
But I think that this patch still works ok with any 32-bits ppc models.  
The reason is that the current 32-bits ppc kernel don't support 
PTRACE_SET_DEBUGREG, so the run-time check in ppc_linux_check_watch_resources
will fail and hence there won't be any difference than the unpatched GDB.
Any different opinion on this?

Another issue I can think of is that Anton's patch to return stopped data
address upon DABR hit is not in the upstream kernel yet.  But I believe 
that there won't be many objection for that, provided that it will only
impact debugger behavior. If it is a pre-requirement for this patch to go
into gdb, I can ping Anton to get his patch into kernel first.

Are there any other issues? Maybe some documents or testcase?  If it is
needed, I can add a testcase for rwatch/awatch or some words somewhere.

These are all I can think of at this time.  Did I miss something?  Your 
comments/suggestion are highly appreciated!

Regards
- Wu Zhou


             reply	other threads:[~2006-01-06  5:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-06  5:41 Wu Zhou [this message]
2006-01-08 22:57 ` Ben Elliston

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=Pine.LNX.4.64.0601061335390.18087@localhost.localdomain \
    --to=woodzltc@cn.ibm.com \
    --cc=anton@au1.ibm.com \
    --cc=bje@au1.ibm.com \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=uweigand@de.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