From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Mark Kettenis , Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: [RFC] Unified watchpoints for x86 platforms Date: Thu, 15 Feb 2001 10:41:00 -0000 Message-id: <1010215184135.ZM8866@ocotillo.lan> 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> X-SW-Source: 2001-02/msg00181.html 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 > proposing. 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. Kevin