This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
About the patch to add h/w watchpoint to ppc arch
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc: drow at false dot org, eliz at gnu dot org, mark dot kettenis at xs4all dot nl, kevinb at redhat dot com, uweigand at de dot ibm dot com, bje at au1 dot ibm dot com, anton at au1 dot ibm dot com
- Date: Fri, 6 Jan 2006 13:41:18 +0800 (CST)
- Subject: About the patch to add h/w watchpoint to ppc arch
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