From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Michael Snyder Cc: kettenis@wins.uva.nl, gdb-patches@sources.redhat.com Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support Date: Wed, 28 Mar 2001 01:30:00 -0000 Message-id: References: <3AC0F081.5923D16D@cygnus.com> X-SW-Source: 2001-03/msg00518.html 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.