This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Date: Mon, 04 Jan 1999 17:19:34 -0800 From: "J.T. Conklin" <jtc@redbacknetworks.com> The reason I dislike the idea of GDB manipulating debug registers directly has more to do with the state of GDB's internals than it does with the concept itself. Those who study recent snapshots will notice that we are doing some internal cleanup that will make it easier to support CPU variants without kludging. My general principle for this kind of thing is that GDB should be able to support both direct manipulation of target resources, as well as the use of a target-side agent to do the same thing. For instance, if you want to use hardware watchpoint registers with a JTAG/BDM setup that has no target-side agent at all, then GDB must do the register manipulation itself. Conversely, when interacting with a workstation OS, GDB must (almost) always go through the OS to be successful. Ideally, GDB would provide internal modules for operations that may be hardware-specific, similar to mem-break, that backend writers can use as needed, and it should provide interfaces to them through the target vector. We've been very inhibited about adding to the target vector over the past couple years, but there is really no penalty for doing so, and with the new setup strategy, it's possible to add fields without tracking down and modifying every target_ops in sight. So I expect to see more things go through the proper internal interfaces, rather than around them. Stan