From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: msnyder@redhat.com Cc: eliz@is.elta.co.il, msnyder@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support Date: Tue, 27 Mar 2001 15:51:00 -0000 Message-id: <200103272351.f2RNpaj01860@delius.kettenis.local> References: <200103270911.f2R9BX421793@debye.wins.uva.nl> <3AC0C4FE.1397@redhat.com> X-SW-Source: 2001-03/msg00514.html Date: Tue, 27 Mar 2001 08:51:10 -0800 From: Michael Snyder Mark Kettenis wrote: > > Date: Tue, 27 Mar 2001 08:55:00 +0200 (IST) > From: Eli Zaretskii > > On Mon, 26 Mar 2001, Michael Snyder wrote: > > > Guys, this implementation has problems. You have it hard-coded > > so that on a linux host, it unconditionally calls native linux > > methods involving ptrace to get the debug registers. This breaks > > very badly if you're using a native linux host to debug a remote > > i386 target. > > Just like the old implementation. I suspect the old implementation > just happened to work because it didn't do any strict error checking. No, you're on the wrong track. I haven't looked at how the old implementation worked, but the problem with the new implementation is _not_ the perror call. It's the ptrace call that preceeds it. You can't call ptrace if the process you're debugging is remote. Did you actually try my patch? I just did, using gdbserver (which by the way needs some fixing for Linux/x86, I'll see what I can do), and it seems to fix the problems for me. Note that it isn't really a problem to call ptrace if the process you're debugging is remote. You'll just call ptrace on untraced (and possibly non-existing) process, and it will fail with ESRCH. > The fundamental problem is that the watpoint-stuff isn't part of the > target vector. Yes, you're absolutely right about this. This is why I don't like ptrace calls being made from outside of the target vector. Me neither, but this seems a reasonable temporary workaround for the problem, especially since GDB has been doing something similar for quite some time. Mark