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
next 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