From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sources.redhat.com
Subject: Re: [RFC] Unified watchpoints for x86 platforms
Date: Thu, 15 Feb 2001 13:26:00 -0000
Message-id: <200102152126.QAA15597@indy.delorie.com>
References: <200009070855.EAA00749@albacore> <200009071500.LAA07756@indy.delorie.com> <200009081529.e88FTjx15960@debye.wins.uva.nl> <200102101533.KAA10417@indy.delorie.com> <200102151146.NAA28431@is.elta.co.il> <s3ilmr72a5u.fsf@debye.wins.uva.nl> <200102151732.MAA04871@indy.delorie.com> <200102151833.f1FIXeq00241@delius.kettenis.local>
X-SW-Source: 2001-02/msg00189.html

> Date: Thu, 15 Feb 2001 19:33:40 +0100
> From: Mark Kettenis <kettenis@wins.uva.nl>
> 
> So please use the names I suggest above.

Will do.

> I think they're much clearer.

Yes, I prefer them as well.

>    > Why not have simply long I386_GET_DR(int regnum) and I386_SET_DR(int
>    > regnum, long value) and let the system-dependent decide how to map the
>    > debug register number ([0..7], as used in the Intel documentation)
>    > into whatever is needed?
> 
>    Why bother the target end to do that?  They will all do the same, and
>    the code I'll write knows exactly when it needs what register.
> 
> It would make the implementation on Linux easier :-).

Could you please explain in a few words why?  Even if I don't change
the interface, I think it is important for me to know about such
subtle aspects.

What I see in i386v-nat.c is that each of these macros maps directly
into a ptrace call with appropriate arguments.  For example, here's
how DR7 (the debug control register) is set:

  ptrace (6, pid, offsetof (struct user, u_debugreg[DR_CONTROL]),
	  debug_control_mirror);

and here's how DR6, the debug status register, is fetched:

  status = ptrace (3, pid, offsetof (struct user, u_debugreg[DR_STATUS]), 0);

Even ia64-linux-nat.c does something very similar, even though it is
not one of the potential customers of what I'm about to write.