This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Unified watchpoints for x86 platforms
- To: Mark Kettenis <kettenis at wins dot uva dot nl>, Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: [RFC] Unified watchpoints for x86 platforms
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Thu, 15 Feb 2001 11:41:35 -0700
- Cc: gdb at sources dot redhat dot 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> <email@example.com>
On Feb 15, 5:17pm, Mark Kettenis wrote:
> > > I started working on the unified support for hardware-assisted
> > > breakpoints and watchpoints on x86 platforms (see TODO). Since I
> > > don't feel I know enough about all the aspects of this on any platform
> > > but DJGPP, I thought I'd better get the framework agreed to before I
> > > start coding.
> > >
> > > Here's the API I suggest for use by higher-level GDB code:
> > >
> > > (Note: I'm not good at inventing names, so please suggest better
> > > ones if you want.)
> > >
> > > int i386_hwbp_insert (int pid, CORE_ADDR addr, int len, int kind);
> Is there any particular reason why you need the PID argument? AFAICS
> it will always be equal to INFERIOR_PID, so I think we can do without
> it. This is also true for the other i386_hwbp_* functions you're
I think it'd be better to not rely on ``inferior_pid''. I would
rather see the explicitly passed. There will come a day when GDB
is able to debug more than one process at a time and to perpetuate
reliance on inferior pid would be short sighted.
> > > In the discussion we had back in September, Mark said that the
> > > status register should be per thread. Does that mean that we need
> > > an additional argument (int tid?) to pass to HWBP_GET_STATUS? If
> > > so, how will this argument get into the i386_hwbp_* functions which
> > > will call these macros?
> I don't think an additional argument is needed. When calling
> HWBP_GET_STATUS, it is the current thread that has encountered a trap,
> and INFERIOR_PID should be set appropriately.
> > > Or maybe the target end can figure out the thread id by itself with
> > > some TIDGET(pid) magic?
Hopefully I'll find time to merge my pid/tid/lwp patch sometime soon.
When this occurs, you'll be able to extract the thread id from what is
now the pid argument.
I have read the rest of Eli's proposal as well as Mark's comments and
I agree with the rest of Mark's remarks.