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: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
- From: Michael Snyder <msnyder at redhat dot com>
- Date: Tue, 27 Mar 2001 08:47:16 -0800
- CC: Michael Snyder <msnyder at cygnus dot com>, Mark Kettenis <kettenis at wins dot uva dot nl>, gdb-patches at sources dot redhat dot com
- References: <Pine.SUN.3.91.1010327085422.19916E-100000@is>
Eli Zaretskii wrote:
>
> 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.
>
> Sorry, I'm not following. The watchpoint-related macros are defined
> on files which should be used only with native debugging (i386-nat.c
> and nm-i386.h). On top of that, the macros only get exposed if the
> port defines I386_USE_GENERIC_WATCHPOINTS. A port which doesn't want
> that should get rid of the watchpoints for free, by simply not
> defining I386_USE_GENERIC_WATCHPOINTS.
>
> Which part of the above misfires, and why?
The gdb was configured for native linux, but until this change,
it was also able to be used to debug a remote embedded i386
target. This change breaks that, because it makes ptrace calls.
If debugging target remote, there is no process on the host machine
on which to make a ptrace call.
>
> > Seems to me, what you need to do is add these debug registers to the
> > reg cache, and treat them like ordinary registers.
>
> This possibility has been discussed back in November, but the
> conclusion was that it's not a good idea. I don't remember the
> details, but the reasons had something to do with threads and how
> the register cache is used in conjunction with threads. (I can dig
> out the URLs of the relevant messages, if you want to read them.)
>
> > Then you can just use the ordinary read_register interface to get
> > them, and remote.c will do the right thing for you (assuming the
> > target knows about these extra registers).
>
> Mark explicitly didn't want the watchpoint code to be in the
> target-depenent files, so watchpoints cannot currently work for remote
> targets.
I don't mind if watchpoints don't work for remote targets --
but the code as written prevents me from debugging a remote
target at all.