This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
pending/1006: Hardware Watchpoint/Breakpoints and Remote Protocol
- From: Steven Johnson <sjohnson at neurizon dot net>
- To: gdb-gnats at sources dot redhat dot com
- Date: Fri, 31 Jan 2003 15:05:56 +1000
- Subject: pending/1006: Hardware Watchpoint/Breakpoints and Remote Protocol
>Number: 1006
>Category: pending
>Synopsis: Hardware Watchpoint/Breakpoints and Remote Protocol
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Fri Jan 31 05:58:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
>Description:
This is a multi-part message in MIME format.
--------------080003090501000107020008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
The support for Hardware Watchpoints and Breakpoints in the remote
protocol is currently unusable. The code is all there (mostly) but it
can never be activated because it is forced to think all targets have no
resources to support these. Currently there is no way to make the
remote protocol think anything other.
Attached is a patch that creates two commands from GDB to allow the
number of Hardware Watchpoints and Breakpoints supported by a remote
target to be set to something other than zero. Doing this makes them
work good.
Ideally, the target would be interogated to find out what it supports,
but that is a bigger harder patch and would require much greater work
than this simple fix. (Arguably for little real gain).
Its also not very accurate, because sometimes hardware allows (for
example) different numbers of watchpoints, depending on the type of
watchpoints that have been set. (The MPC8XX watchpoint unit for example).
Comments welcome, it works excellent for me using Motorola MPC862
Hardware watchpoint support, and a BDM interface communicating to GDB
with the remote protocol over TCPIP.
The patch was made against a version of GDB just prior to V5.3, but it
applies to V5.3 fine.
Regards,
Steven
--------------080003090501000107020008
Content-Type: application/x-java-vm;
name="patch-enable-hw-remote-features"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="patch-enable-hw-remote-features"
ZGlmZiAtQzIgLXIgLWIgZ2RiX2N2cy9zcmMvZ2RiL3JlbW90ZS5jIGdkYl9hbHRlcmVkL3Ny
Yy9nZGIvcmVtb3RlLmMKKioqIGdkYl9jdnMvc3JjL2dkYi9yZW1vdGUuYwlGcmkgTm92IDE1
IDEwOjUzOjU0IDIwMDIKLS0tIGdkYl9hbHRlcmVkL3NyYy9nZGIvcmVtb3RlLmMJVGh1IEph
biAgMiAxNjowMTowNiAyMDAzCioqKioqKioqKioqKioqKgoqKiogNDg0MCw0ODQ1ICoqKioK
ICAKICAKISBpbnQgcmVtb3RlX2h3X3dhdGNocG9pbnRfbGltaXQgPSAwOwohIGludCByZW1v
dGVfaHdfYnJlYWtwb2ludF9saW1pdCA9IDA7CiAgCiAgaW50Ci0tLSA0ODQwLDQ4NDUgLS0t
LQogIAogIAohIHN0YXRpYyBpbnQgcmVtb3RlX2h3X3dhdGNocG9pbnRfbGltaXQgPSAwOwoh
IHN0YXRpYyBpbnQgcmVtb3RlX2h3X2JyZWFrcG9pbnRfbGltaXQgPSAwOwogIAogIGludAoq
KioqKioqKioqKioqKioKKioqIDYxNTMsNjE1NiAqKioqCi0tLSA2MTUzLDYxNzIgLS0tLQog
ICAgICAgJnNob3dsaXN0KTsKICAKKyAgIGFkZF9zaG93X2Zyb21fc2V0CisgICAgIChhZGRf
c2V0X2NtZCAoInJlbW90ZS1ody1icmVha3BvaW50cy1hdmFpbGFibGUiLCBjbGFzc19vYnNj
dXJlLAorIAkJICB2YXJfaW50ZWdlciwgKGNoYXIgKikgJnJlbW90ZV9od19icmVha3BvaW50
X2xpbWl0LAorIAkJICAiU2V0IHRoZSBtYXhpbXVtIG51bWJlciBvZiBoYXJkd2FyZSBicmVh
a3BvaW50cyBcCisgc3VwcG9ydGVkIGJ5IHRoZSB0YXJnZXQuXG4iLFwKKyAJCSAgJnNldGxp
c3QpLAorICAgICAgICAgICAgICAgICAgICZzaG93bGlzdCk7CisgCisgICBhZGRfc2hvd19m
cm9tX3NldAorICAgICAoYWRkX3NldF9jbWQgKCJyZW1vdGUtaHctd2F0Y2hwb2ludHMtYXZh
aWxhYmxlIiwgY2xhc3Nfb2JzY3VyZSwKKyAJCSAgdmFyX2ludGVnZXIsIChjaGFyICopICZy
ZW1vdGVfaHdfd2F0Y2hwb2ludF9saW1pdCwKKyAJCSAgIlNldCB0aGUgbWF4aW11bSBudW1i
ZXIgb2YgaGFyZHdhcmUgd2F0Y2hwb2ludHMgXAorIHN1cHBvcnRlZCBieSB0aGUgdGFyZ2V0
LlxuIixcCisgCQkgICZzZXRsaXN0KSwKKyAgICAgICAgICAgICAgICAgICAmc2hvd2xpc3Qp
OworICAgICAgIAogICAgYWRkX3BhY2tldF9jb25maWdfY21kICgmcmVtb3RlX3Byb3RvY29s
X2JpbmFyeV9kb3dubG9hZCwKICAJCQkgIlgiLCAiYmluYXJ5LWRvd25sb2FkIiwK
--------------080003090501000107020008--
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: