This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Wed, 28 Mar 2001 11:28:24 +0200 (IST)
- cc: kettenis at wins dot uva dot nl, gdb-patches at sources dot redhat dot com
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.