Re: [PATCH]: Make Linux use the new unified x86 watchpoint support

[Eli Zaretskii <eliz@is.elta.co.il>]

On Tue, 27 Mar 2001, Michael Snyder wrote:

> > How does GDB know if the target is local or remote?  Can the Linux
> > implementation of I386_DR_LOW_* macros test that and avoid calling
> > ptrace in that case?
> 
> If you say "run" it's native -- if you say "target remote /dev/tty0"
> it's remote.  Or did you mean how can you tell programmatically?

Programmatically, yes.

> There is no clean way, other than to test "current_target", eg.
> 	if (strcmp (current_target.to_shortname, "remote") == 0)
> and that's obviously not the nicest approach.

It's not nice, but I386_DR_LOW_* macros (or the Linux-specific
functions they call) could make such a test and avoid ptrace, if that
is the source of trouble.

However, Mark seems to tell that his simpler band-aid also works.

In the longer run, we could make watchpoints work even in remote
debugging, provided that there's a facility in the remote protocol to
fiddle with debug registers (sorry, I don't know anything about the
remote protocol, so I might be saying something stupid).  Just make
the Linux-specific implementations of I386_DR_LOW_* macros send the
right packet if the target's name is "remote".

> I've no idea, I just know that it suddenly stopped working
> with these changes.  And I'm not talking about watchpoints
> working -- I'm talking about _anything_ working.  There is a
> call to STOPPED_BY_WATCHPOINT in wait_for_inferior, and
> you can't even connect to the target without wait_for_inferior
> being called.

Actually, that call to STOPPED_BY_WATCHPOINT is IMHO totally bogus: no
one looks at the result it returns, and I have yet to see any
implementation of watchpoints that needs that call.

I'm guessing that this call goes back to the implementation for 
Sparclite, which uses this call to produce a side effect (to be able
to step over the instruction which caused the watchpoint to trigger),
see config/sparc/tm-sparclite.h.  Since this seems to be the only 
platform which needs a side effect, and since we already have an 
equivalent mechanism for doing the same, with the HAVE_*_WATCHPOINT 
macros, I think this call can be removed.