Runtiming hw watchpoints; Was: Split up Z packet enable/disable cmd

[Andrew Cagney <ac131313 at cygnus dot com>]

(I'm going to think out loud...)

> 
> There are 3 new target vector entries:
> to_Z_packet_supported_p
> to_insert_watchpoint
> to_remove_watchpoint

From memory watchpoints can be implemented at two levels:

	o	GDB directly pokes watchpoint
		registers

	o	GDB asks the target to take
		care of the problem

First thing to keep in mind is that everytime this is pointed out the
discussion goes off on a religious tangent where people argue how one or
the other is the only correct solution ...  I think they both are
equally correct :-)

Something less target specific than to_Z_packet_supported_p() is going
to be needed :-)

> > PS: It doesn't fix the compile time test for remote watchpoints but it
> > does enable the code always (so that I've a better chance of not
> > breaking it :-).
> >
> Well, my patch takes care of that part. This is a good opportunity to ask what
> people think of my solution.  It is working on a beta version and a candidate
> for being submitted as a complement to Andrews patch.
> 
> I have set TARGET_CAN_USE_HARDWARE_WATCHPOINT to a function which will call
> target_Z_packet_supported_p().  remote_Z_packet_supported_p() sends a "probe"
> packet if the support is set to auto and we haven't asserted if the target
> accepts or not the Z packet (OK, I will have to make it Z4 or something).
> 
> If the Z-packet support is in auto and we have not connected to the target yet,
> we cannot access if watchpoints are allowed (if it is set to enabled or disabled
> we assume the user knows).  In this case I print:
> "Cannot set watchpoints before connecting to remote target: Z-packet support unknown."
> 
> That is the only real restriction.  As I don't meddle at all with the breakpoint.c
> code it results in a very simple fix.

I don't think this is reasonable.  I think a better model would involve:

	(gdb) watch c
	Watchpoint 1: c

	(gdb) watch b
	Watchpoint 2: b

	(gdb) target xxx

	(gdb) try-watchpoints-for-size OR run
	Watchpoint 1 hardware
	Watchpoint 2 doesn't fit

	(gdb) run

I.E. delay assigning watchpoints to hardware/software until the last
moment.  Instead of having watch_command_1()  try to select a hw/sw
watchpoint before it knows the answer, the code inserting the watchpoint
could do it and just set ->hw if it succeeded.

From memory, GDB refuses to mix hardware and software watchpoints which
should greatly simplify the implementation.

	Andrew